Subject: Re: [boost] [persistent] Library preview: Persistent
From: Stefan Strasser (strasser_at_[hidden])
Date: 2013-03-04 13:01:42
Am 04.03.2013 16:52, schrieb Jarrad Waterloo:
> So if your library is in need, which it is, than release it, preferably
> to boost under the boost license. You can always improve, add on latter.
> You may solicit architecture and requirements from the list to increase
> its usefulness and minimize rewrites. If you can't provide enough
> manpower to complete it or even if you can, than solicit help. If four
> people throughout the world can get it done in half the time of one
> person than WOO HOO! There are many who would like to contribute from
> the beginning, which also can't hurt acceptance. The important thing is
> to have a vision, preferably shared, and to release something usable,
> useful and working, as quickly as possible before interest dries up and
> in a timely manner.
Thanks for your remarks!
Specifically for Persistent:
> Have you considered an MVCC [option] where there are no updates from a
> users perspective but are rather inserts; This sacrifices hard drive
> space for a lock free/low lock database.
yes, the entire storage backend is based on MVCC . there currently is
no lock-based option. objects are MVCC in memory for concurrency (see
section "concurrent transactions" ), and on disk to achieve atomic
updates. when an update is safely synced to disk the old object versions
I haven't written much about the backend in the documentation for two
reasons: the interface is most important, and I actually don't think it
would get used much in the long term.
as much as I try to make it safe and efficient, a backend using an
industrially proven storage engine like BerkeleyDB or SQLite would
almost always be preferred, if the stored data has any value.
I've written more about this in a previous reply to Klaim-Joël Lamotte
in this thread.
Would you like to share anything on the architecture of the interface?
> Since you in some ways may be competing against relational databases by
> making a object oriented database, maybe equivalent administrative
> functionality are in order such as import and export into some textual
> On a related note, ways to access system information such external
> id/OIDS, timestamps, version numbers via an API for tooling and maybe
> querying purposes
> ?File format specifications?
this and much more is certainly needed for database applications. but
since we don't have the resources to implement an industrial-strength
storage engine, my approach was to provide one "black-box"
implementation for applications that would have used
(boost.)serialization or other files otherwise, and provide resource
managers using external databases later on.
> Concerning my interest, why haven't you given this to me two years ago,
> how much longer must I wait. [Ha Ha Ha]
*pointing to the copyright notice* :p
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk