'Lite' Databases (Re: sqlite3 and dates)

[Mark Lawrence]

On 20/02/2015 21:17, Paul Rubin wrote:
> Ben Finney <ben+python at 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