Re: [boost] [persistent] Library preview: Persistent

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 [1]. there currently is 
no lock-based option. objects are MVCC in memory for concurrency (see 
section "concurrent transactions" [2]), and on disk to achieve atomic 
updates. when an update is safely synced to disk the old object versions 
are discarded.

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
> representations.
> 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

Regards,

Stefan

[1] http://en.wikipedia.org/wiki/Multiversion_concurrency_control
[2] 
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/transactions.html#persistent.transactions.concurrent