Bob Walters wrote:
I have a library I would like to submit for inclusion in Boost. This message is just soliciting for interest per the submission process. If interest is expressed, I'll carry on with a preliminary submission.
The library is an embedded database, to the tune of products like the embedded version of InnoDB, BerkeleyDB, etc. In this case, the database is structured as a Boost.interprocess shared region (typically mmap so it can page) which contains one or more STL-like containers holding application defined data types in directly usable form (i.e. not serialized.) The database infrastructure is fully ACID compliant, with durability via write-ahead logging, and periodic checkpoints. More details, examples, and documentation is available at http://stldb.sourceforge.net/ for more details on this libraries capabilities.
Currently, I've only implemented map<> (probably the most useful container type in a database), but the plan is to continue to add containers as requested/needed until ACID compliant versions of a decent portion of the STL are available.
Very interesting. I've written a std::map interface to Berkeley DB, which gives quite some of functionality. Taken from that, I have a couple of questions, 1) Transactional semantics: wouldn't it be easier to steal semantics from locks in threads? E.g., for the synchronous interface case, wouldn't map_type m_map; try { scoped_transaction trans( m_map ); .. .. do stuff with the map .. trans.commit(); } catch( transaction_error ) { } be a easier than passing the transaction everywhere? 2) what serialization models are you considering? I.e., for a map of int to doubles, serialization would be overkill, wouldn't it? 3) have you considered things like key prefix-compression and storing keys and values in different files? 4) how did you solve "map[ key ] = value" vs something = map[ key ]? Here, I resorted to a reference object that would do the .put() in case of assignment, a .get() in case of an implicit conversion. 5) do you reach 200,000 transactions per second per thread? :-) What would be really nice is something like a stored version of multi_index. Thanks, Cheers, Rutger