On 20/02/2015 21:17, Paul Rubin wrote:
Ben Finney <ben+pyt...@benfinney.id.au> writes:
I don't know of a free-software concurrent RDBMS which can be considered
lighter than that. (No, MySQL doesn't count; its concurrency is
*unreliable* and it commonly loses data silently. Don't use MySQL.)
I thought they fixed MySQL transactions years ago, with the InnoDB
engine. For some reason it's not the default, so you have to turn it on
explicitly: is there more to it than that?
For stuff like browser bookmarks or other typical embedded database
purposes, I don't see why SQL or relations are needed. Berkeley DB is a
transactional key-value store that's been around for decades and is way
simpler than SQLite, and there's other things like that too.
I thought I recognised the name, so a quick search and found it was
deprecated in Python 2.6, removed from 3.0. Supported bindings
available here https://www.jcea.es/programacion/pybsddb.htm for anybody
who's interested.
SQLite always seemed bloated (from the embedded NoSQL point of view) and
fragile to me, and the vendor plays an annoying anti-forking trick,
which is that the code is released but the developers' test suite is
secret and proprietary (can be licensed from them for big bucks). So if
you want to make your own version of SQLite you have to either pay for
the test suite, or have much less reliability assurance for your patched
version than the vendor has for their version. Add that Sqlite is
written in C (think of naked whirling razor blades) and you've got a
pretty serious disincentive against modification.
Thanks for the above. I've been meaning to take a look at how SQLite is
tested for months if not years. That saves me the trouble :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list