Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43297 > unrolled thread

python-noob - which container is appropriate for later exporting into mySql + matplotlib ?

Back to article view | Back to comp.lang.python

Contents

  python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-11 00:06 +0200
    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-11 01:39 +0000
      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-11 10:49 +0200
        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-11 15:38 +0200
    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-11 17:58 +0000
      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-11 18:44 +0000
        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-12 16:19 +0200
      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-11 21:42 +0200
      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-12 16:03 +0200
        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-12 16:58 +0000
          Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-12 22:52 +0200
            Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-12 23:26 +0000
              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 02:00 +0200
              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-13 01:44 +0000
                Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 13:08 +0200
                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-13 21:39 +1000
                    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 15:30 +0200
                      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 00:03 +1000
                        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Roy Smith <roy@panix.com> - 2013-04-13 10:36 -0400
                          Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 21:25 +0200
                            Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Roy Smith <roy@panix.com> - 2013-04-13 17:38 -0400
                        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 16:39 +0200
                          Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Walter Hurry <walterhurry@lavabit.com> - 2013-04-13 14:56 +0000
                            Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 21:34 +0200
                              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Walter Hurry <walterhurry@lavabit.com> - 2013-04-13 22:22 +0000
                                Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-14 00:31 +0200
                                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 08:54 +1000
                                    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-14 02:06 +0200
                              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 08:34 +1000
                                Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-14 02:10 +0200
                          Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 02:15 +1000
                            Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? rusi <rustompmody@gmail.com> - 2013-04-13 10:02 -0700
                              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 21:49 +0200
                              Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-14 07:56 +0000
                                Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? rusi <rustompmody@gmail.com> - 2013-04-14 04:17 -0700
                                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 23:22 +1000
                                    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? rusi <rustompmody@gmail.com> - 2013-04-15 04:45 -0700
                                      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-15 22:28 +1000
                                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Ned Deily <nad@acm.org> - 2013-04-14 09:40 -0700
                                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Tim Chase <python.list@tim.thechases.com> - 2013-04-14 15:16 -0500
                                    Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Roy Smith <roy@panix.com> - 2013-04-14 17:48 -0400
                                  Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-15 07:43 +1000
                            Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 21:42 +0200
                      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-13 16:01 -0400
                        Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? someone <newsboost@gmail.com> - 2013-04-13 23:36 +0200
                      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Chris Angelico <rosuav@gmail.com> - 2013-04-14 08:44 +1000
                      Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-13 19:42 -0400
                Re: python-noob - which container is appropriate for later exporting into mySql + matplotlib ? Cousin Stanley <cousinstanley@gmail.com> - 2013-04-14 18:20 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#43582

In article <mailman.605.1365973547.3114.python-list@python.org>,
 Tim Chase <python.list@tim.thechases.com> wrote:

> I'd really love if there was a simple DNS-lookup module available in 
> the stdlib, especially if it allowed overriding the server to ask.

pip install dnspython

[toc] | [prev] | [next] | [standalone]

#43581

On Mon, Apr 15, 2013 at 2:40 AM, Ned Deily <nad@acm.org> wrote:
> In article
> <CAPTjJmrP_9saiG89DKse-P6D0kPBjXMfe1731dfFAguKvaSO+Q@mail.gmail.com>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>  > Actually, this is one place where I disagree with the current decision
>> of the Python core devs: I think bindings for other popular databases
>> (most notably PostgreSQL, and probably MySQL since it's so widely
>> used) ought to be included in core, rather than being shoved off to
>> PyPI. Databasing is so important to today's world that it would really
>> help if people had all the options right there in core, if only so
>> they're more findable (if you're browsing docs.python.org, you won't
>> know that psycopg is available). Currently the policy seems to be "we
>> don't include the server so why should we include the client"; I
>> disagree, I think the client would stand nicely on its own. (Does
>> Python have a DNS server module? DNS client? I haven't dug deep, but
>> I'm pretty sure I can do name lookups in Python, yet running a DNS
>> server is sufficiently arcane that it can, quite rightly, be pushed
>> off to PyPI.) But this is minor, and tangential to this discussion.
>
> For the bindings to be useful, Python batteries-included distributions
> (like python.org installers) would either need to also ship the various
> DB client libraries for all supported platforms (including Windows),
> which adds complexity and potentially intractable license issues, or
> there would need to be reverse-engineered implementations of the client
> libs or wire protocols, either option adding fragility and complex
> testing issues.  DNS client lookups use published, well-understood
> Internet-standard protocols, not at all like talking to a third-party
> database, be it open-source or not.  Sqlite3 is certainly an anomaly in
> that it is not-only open source but designed to be a lightweight,
> compatible library that runs on just about everything, and with a
> fanatical devotion to compatibility and documentation.  These days just
> about every major product or operating system platform ships with or
> uses a copy of sqllite3 for something.

Understandable, but I'm actually referencing a discussion on either
python-dev or python-ideas where the statement was made that it didn't
make sense to include the client for something that the server for
wasn't included. I can't find the discussion thread off-hand, but
that, rather than the portability/complication issues, seemed to be
the primary line of argument.

I don't know about any others, but PostgreSQL's wire protocol isn't
all that difficult to work with, and since we're talking about
something where the far end is almost certainly going to consume some
time, it wouldn't hurt to implement it in pure Python. Based on
http://wiki.postgresql.org/wiki/Python it seems there are a few
modules that do just that (unchecked, but if they work on any platform
and don't require libpq, I strongly suspect they use Python's own
networking); if one of those is of sufficient code quality for the
stdlib, I think it would be an excellent addition. However, I am not a
core dev, therefore sqlite is the only one included.

ChrisA

[toc] | [prev] | [next] | [standalone]

#43541

On 04/13/2013 06:15 PM, Chris Angelico wrote:
> On Sun, Apr 14, 2013 at 12:39 AM, someone <newsboost@gmail.com> wrote:
>> On 04/13/2013 04:03 PM, Chris Angelico wrote:
>>> Failure at any level means the overall system is not ACID compliant.
>>
>> Roger... But google says sqlite is supposed to be ACID compliant (although
>> maybe not "fully" as you indicate, I'm not sure about this)...
>
> What your Google hits are telling you is that sqlite can (if
> configured correctly) pass level 2. But it doesn't guarantee anything
> about the other levels, so it's easy to have an, uhh, ACID leak.

Ok, thank you very much, this is something I couldn't easily see in the 
first place... I think what I should do now is to play a bit with sqlite 
and then afterwards, when I'm happy I would begin to play with 
postgresql and be very happy with it, knowing that I can (hopefully) use 
that for all important projects in the rest of my life :-)

I might also play a bit with mySql, because it's my impression that it 
also have a big user-group. But I read that postgresql is MUCH more 
"safe" to use (and a bit slower) than postgresql which on the other hand 
is VERY safe, being fully ACID-compliant...

>>> You'd have to actually test it. The easiest way is to get two
>>> computers, side by side, and run the database engine on one and a
>>> monitor on the other.
>>
>> Ok, that doesn't sound to be so simple after all...
>
> I gave a fairly wordy run-down of what I tested, but it's actually
> fairly simple in concept: Do a huge bunch of transactions, and keep a
> log of what's returned from the COMMIT query; then pull the power out.

I'll try it (or something similar) out one day in the future and see 
what happens with the "corrupted" changes due to pulling out the network 
cable while transmitting data...

>> Ok, it would be nice to hear/read the opinion from another in here who've
>> been working (a lot?) with sqlite...
>
> Agreed. I'm sure someone will chime in.
>
>> I'm not so rich, so I prefer to go for a free database solution rather than
>> an expensive license... I've heard good things about oracle and that's also
>> what they used at my previous company, but it's not something I am willing
>> to pay for, from my private/own money for my sparetime-projects...
>
> I concur with Walter's assessment: You want PostgreSQL. It's free/open
> source software (highly permissive MIT-like license), massively
> trusted, and scales up beautifully. (That last one may not be
> significant to you, but it's still good to know your database can
> handle hundreds or thousands of tps on basic hardware.)

I understand that scaling is VERY important and if I could choose 
between two "equally" opensource systems and one of them scales better 
than the other, I would definately work with the one that scales the 
most - that means that I don't have to learn how to use a whole new 
system, if I already learnt the system that scales best...

And I just found on google that yahoo runs a HUGE PostgreSQL database... 
Very interesting - I'll definately try to play around with postgreSQL at 
some time in the future...

[toc] | [prev] | [next] | [standalone]

#43543

On Sun, 14 Apr 2013 00:03:25 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> True ACID compliance demands support at every level:
> 
> 1) The application has to operate in logical units of work, which -
> apart from with DB2 - requires an explicit "BEGIN" query, or
> single-statement transactions.
>
	While SQLite3 normally runs in an auto-commit mode, the Python
DB-API spec, in general, requires that auto-commit be turned off. "The
Definitive Guide to SQLite" states that the Python adapter scans
queries, and will start a transaction if the query is one that will
change data (insert/replace/update). Read-only queries stay auto-commit
until one of the data change queries is submitted and not committed.

> 
> 3) The operating system and filesystem must support a forced file
> synchronization (fsync/fdatasync), so the database engine can wait for
> the data to be written to disk.
> 
> 4) The underlying media (hard disk, SSD, USB stick, etc) must respond
> to the fsync call by actually writing the content to persistent
> storage before returning.
> 
> Failure at any level means the overall system is not ACID compliant.
> PostgreSQL has a huge amount of code in it to try to deal with (or at
> least recognize) a level-3 failure, but nothing in the database engine
> can deal with level 1 or 4 issues.
> 
> You'd have to actually test it. The easiest way is to get two
> computers, side by side, and run the database engine on one and a
> monitor on the other. To test some SSDs at work, I knocked together a
> little program that worked somewhat thus:
> 
> * Connect to the database over TCP/IP (easy, as we were doing this
> with PostgreSQL)

	You don't with SQLite -- or, properly, it is not to an SQLite
port... It would be something like an NFS mounted file share -- and we
all know how uncertain file locking is over NFS. <G>

> * Create a table with a number of rows with an ID and a counter,
> initialized to 0
> * Repeatedly, in parallel, perform a transaction:
>   - Increment the counter on one of the rows (at random)
>   - Increment a "possible" in-memory counter for that row
>   - Commit the database transaction
>   - Increment a "confirmed" in-memory counter for that row
> * When an error of "database seems to be down" is detected, wait for
> it to come up again, then query the table. The counters must all be at
> least their corresponding "possible" value and at most the
> "confirmed".
>
	SQLite is a "file server" database (like M$ JET engine [aka:
"Access"]). It's locking system is multi-stage. It allows multiple
concurrent readers on a "shared" lock state. Only one connection can
perform write operations ("reserved" lock) alongside the readers. A
second connection attempting to perform a write will be rejected with a
database locked condition. Then it really gets nasty -- the writer
attempts to commit the update: The first step is to block other
connections from even entering the read state (the "pending" lock).
However, the writer itself is blocked until all remaining readers have
exited; only then does it have exclusive access to and SQLite makes
changes to the database file itself (prior to that, the writer
connection is changing page images in memory)

	So in your example above, the first process to submit an update
command is going to lock all the others from submitting updates AND will
itself be held from committing the update until all the other processes
have closed (commit or rollback their "read sessions"). Since the Python
adapter basically does auto-commit for all until an update is attempted,
the first process to submit the update will get the reserved lock, and
the other reading sessions can pop in and out freely. On the attempt to
commit, the other sessions will be blocked from even entering a read
session, and there should be no other session trying to start a write
transaction, so the odds are that the commit goes through (there is a
very small window in the locking sequence in which two Python
connections that submit update queries might get into the "shared read"
state, and one then has to back out when the other gets the "reserved"
lock.

	In the commit phase, SQLite first tries to ensure the rollback
journal is flushed to disk -- but that apparently is out of its control;
it can submit a sync command to the OS, but has to rely on what the OS
tells it about the state of the writes to disk (the book indicates that
some IDE drives would lie when queried about sync status, while still
having unwritten data in the on-board buffers). After the rollback
journal it submits the data to the database. I

Crash during journal write: restart finds no journal, that transaction
is lost but the database itself is clean

Crash after journal during database update, restart finds journal,
assumes database is suspect, and rolls back the pages, database is
restored to pre-transaction state

Crash after database sync during removal of journal, restart either
finds journal still there and rolls back the pages restoring to
pretransaction state, or the file was removed from the directory and
SQLite determines database file is good with the last transaction in
place.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#43546

On 04/13/2013 10:01 PM, Dennis Lee Bieber wrote:
> On Sun, 14 Apr 2013 00:03:25 +1000, Chris Angelico <rosuav@gmail.com>
> declaimed the following in gmane.comp.python.general:

[ ....]

>> * Create a table with a number of rows with an ID and a counter,
>> initialized to 0
>> * Repeatedly, in parallel, perform a transaction:
>>    - Increment the counter on one of the rows (at random)
>>    - Increment a "possible" in-memory counter for that row
>>    - Commit the database transaction
>>    - Increment a "confirmed" in-memory counter for that row
>> * When an error of "database seems to be down" is detected, wait for
>> it to come up again, then query the table. The counters must all be at
>> least their corresponding "possible" value and at most the
>> "confirmed".
>>
> 	SQLite is a "file server" database (like M$ JET engine [aka:
> "Access"]). It's locking system is multi-stage. It allows multiple
> concurrent readers on a "shared" lock state. Only one connection can
> perform write operations ("reserved" lock) alongside the readers. A
> second connection attempting to perform a write will be rejected with a
> database locked condition. Then it really gets nasty -- the writer
> attempts to commit the update: The first step is to block other
> connections from even entering the read state (the "pending" lock).
> However, the writer itself is blocked until all remaining readers have
> exited; only then does it have exclusive access to and SQLite makes
> changes to the database file itself (prior to that, the writer
> connection is changing page images in memory)

Ok, this makes sense... It's not something I'll bother about to begin 
with, but maybe later (for critical apps) I can see that this is important.

[ ....]

> 	In the commit phase, SQLite first tries to ensure the rollback
> journal is flushed to disk -- but that apparently is out of its control;
> it can submit a sync command to the OS, but has to rely on what the OS
> tells it about the state of the writes to disk (the book indicates that
> some IDE drives would lie when queried about sync status, while still
> having unwritten data in the on-board buffers). After the rollback
> journal it submits the data to the database. I

I agree, this must be a problem, when the OS is lying...

> Crash during journal write: restart finds no journal, that transaction
> is lost but the database itself is clean
>
> Crash after journal during database update, restart finds journal,
> assumes database is suspect, and rolls back the pages, database is
> restored to pre-transaction state
>
> Crash after database sync during removal of journal, restart either
> finds journal still there and rolls back the pages restoring to
> pretransaction state, or the file was removed from the directory and
> SQLite determines database file is good with the last transaction in
> place.

Ok, this is a bit more advanced - I'll try to make my own experiments 
now and then after some time I guess I can dig more into these details, 
thanks.

[toc] | [prev] | [next] | [standalone]

#43552

On Sun, Apr 14, 2013 at 6:01 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sun, 14 Apr 2013 00:03:25 +1000, Chris Angelico <rosuav@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> True ACID compliance demands support at every level:
>>
>> 1) The application has to operate in logical units of work, which -
>> apart from with DB2 - requires an explicit "BEGIN" query, or
>> single-statement transactions.
>>
>         While SQLite3 normally runs in an auto-commit mode, the Python
> DB-API spec, in general, requires that auto-commit be turned off. "The
> Definitive Guide to SQLite" states that the Python adapter scans
> queries, and will start a transaction if the query is one that will
> change data (insert/replace/update). Read-only queries stay auto-commit
> until one of the data change queries is submitted and not committed.

Okay, that's good. Point still stands, though, that the application
has to use BEGIN/COMMIT correctly; the size of the logical unit of
work should be defined by what's one logical action, not by what gives
the best performance.

>> * Connect to the database over TCP/IP (easy, as we were doing this
>> with PostgreSQL)
>
>         You don't with SQLite -- or, properly, it is not to an SQLite
> port... It would be something like an NFS mounted file share -- and we
> all know how uncertain file locking is over NFS. <G>

Sure, but you could easily make a tiny "SQLite server" that accepts
socket connections, reads integers, and writes back "OK" when the
transaction's committed. The only difference is that you have to write
two halves instead of letting the DB itself be the other half.

>> * Create a table with a number of rows with an ID and a counter,
>> initialized to 0
>> * Repeatedly, in parallel, perform a transaction:
>>   - Increment the counter on one of the rows (at random)
>         So in your example above, the first process to submit an update
> command is going to lock all the others from submitting updates AND will
> itself be held from committing the update until all the other processes
> have closed (commit or rollback their "read sessions").

Ah, that'd be a problem. What if each row is in its own file, though?
Would that work? That is, instead of:

UPDATE durability_test_table SET counter=counter+1 WHERE id=:random_value

you use:

UPDATE durability_test_:random_value SET counter=counter+1

(except, of course, that SQL parameterization wouldn't work there, so
it'd be Python string manipulation) - this way, transactions will lock
only against other transactions manipulating the same entry, which is
effectively the same as row-level locking. With 2-3 times as many
"rows" as threads, there should be very little lock contention.

ChrisA

[toc] | [prev] | [next] | [standalone]

#43555

On Sun, 14 Apr 2013 08:44:28 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> 
> Ah, that'd be a problem. What if each row is in its own file, though?
> Would that work? That is, instead of:
> 
> UPDATE durability_test_table SET counter=counter+1 WHERE id=:random_value
> 
> you use:
> 
> UPDATE durability_test_:random_value SET counter=counter+1
> 
	SQLite3 requires one to "attach" other files. 

	ATTACH "file.spec" AS internalname

	If tables in the files share names, you have to use a qualified name
to access them:

	select * from internalname.table

{the original connected database file can be qualified as "main"}

	I'll admit I don't know enough about SQLite3 to know if the locks
are global, or per attached file. The information may be in the book
(the first edition is actually larger than the second edition! and may
have more of the gritty internals described) -- but you'll forgive me if
I don't spend the evening reading to find out. If per file, you could
have an update on each file with no locking conflict between them.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#43573

Steven D'Aprano wrote:

> On Fri, 12 Apr 2013 23:26:05 +0000, Cousin Stanley wrote:
>
>>   The firefox browser keeps different sqlite database files for various
>>   uses ....
>
> Yes, and I *really* wish they wouldn't. 
>
> It's my number 1 cause of major problems with Firefox.

  Problems with software of any flavor,
  especially software that is used regularly
  and upon which we are somewhat dependent,
  are always a source of frustration .... 

  My own personal use of firefox over the years
  has been limited as I have not used it
  for my primary browser and have not experienced
  any problems with its bookmarks .... 

  I use opera as my primary browser
  and would very much like to convert
  the plain-vanilla bookmark.adr file
  that opera uses into an sqlite data base
  for diversity in bookmark searches 
  that would be independent of reglular
  browser usage .... 

    $ grep FOLDER ~/.opera/bookmarks.adr | wc -l
    631

    $ grep URL ~/.opera/bookmarks.adr | wc -l
    14944


> http://kb.mozillazine.org/Bookmarks_history_and_toolbar_buttons_not_working_-_Firefox

  Although there have been many reports entailing corruption 
  of the places.sqlite file, it isn't apparent to me 
  from the link above that sqlite itself is the culprit .... 

  Could the complexity/bugginess of the firefox code
  possibly be the cause instead ?

    "If Firefox works normally when you first open it 
     after starting up the computer but multiple symptoms arise 
     after you close and later reopen Firefox, it's likely 
     that a Firefox process from a previous session 
     did not close properly and the Places database 
     ( "places.sqlite" file ) is locked."


  If you check the headers of any of my posts here
  you will find that I post with a python-based news client
  named XPN that also uses sqlite for persistent storage,
  one sqlite database for each different newsgroup .... 

  I've used xpn daily for many years and have never experienced 
  a corrupted sqlite database file ....

    firefox + sqlite ----> buggy ? ....... :-(

     python + sqlite ----> ok, hooray .... :-)


> Using a database for such lightweight data as bookmarks is, in my 
> opinion, gross overkill and adds to the complexity of Firefox. 
>
> More complexity leads to more bugs, e.g.:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=465684#c11
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=431558

  These pages show problems that are 4 and 5 years old
  from 2008 & 2009 and are marked as Status: RESOLVED FIXED 
  at the top of the page .... 

  Are you still having firefox bookmark problems today ?


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web