I picked SQLite for its minuscule (by today's standards) footprint, simplicity, and ease of deployment.
Why do I get the feeling I've bought into a product like any model in the
American car market. With each passing interation the vehicle gets bigger,
fatter, and less efficient. This continues until the model bears absolutely
no resemblance to the original. But, it does have electric fold down rear
seats to the advantage of the totally clueless.
If all these MySQL and PostgreSQL imitator "features" could be developed as
"plug in" modules that leaves SQLite as it was for those who liked it the
way it was when they picked the product, I would not really care who did
what about complex locking situations.
Guess I need to start "shopping" again :-(
I'm not at all sure why you would draw such a conclusion.
SQLite3 produces smaller data files and is faster, in general, than did SQLite2. It also uses its internal data structures more efficiently.
The ongoing multiple-processes-accessing-the-same-database discussion is specifically focused on not adding client/server, not adding a daemon, and on leveraging filesystem based locking to ensure multiple processes can successfully read/write to a single database file in the most simplistic fashion possible.
The request to have an abuse test was not a request to add some complex locking functionality to SQLite. It was specifically a request to have a test that ensures that the *** already existing locking features *** work correctly when multiple processes are beating upon the database. That is, to test code paths that already exist for which -- at least as far as I can tell -- there is little testing coverage.
How is that bloating SQLite?
b.bum
