On Mon, 27 Aug 2012 14:37:37 +0200, Vincent Pelletier <vinc...@nexedi.com> wrote : > Under the hood, it relies on simple features of SQL databases
To make things maybe a bit clearer, from the feedback I get: You can forget about SQL presence. NEO usage of SQL is as a relational as a handful of python dicts is. Except there is no way to load only part of a pickled dict, or do range searches (ZODB's BTrees are much better in this regard), or writable to disk atomically without having to implement this level of atomicity ourselves. Ideally, NEO would use something like libhail, or maybe even simpler like kyotocabinet (except that we need composed keys, and kyotocabinet b-trees have AFAIK no such notion). SQL as a data definition language was simply too convenient during development (need a new column ? easy, even if you have a 40GB table), and it stuck - and we have yet to find a significant drawback to implement a new storage backend. As a side effect, SQL allows gathering some statistics over the data contained in a database very efficiently. Number of current objects, number of revisions per object, number of transactions, when transactions occured in base history, average object size, largest object, you name it. -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev