|
Boost : |
Subject: Re: [boost] [persistent] Library preview: Persistent
From: Stefan Strasser (strasser_at_[hidden])
Date: 2013-03-04 12:01:15
Am 04.03.2013 13:50, schrieb Klaim - Joël Lamotte:
> I am just a bit confused as the difference, in practice, with storying
> object data always in database.
there is no difference. it defines an interface to storing objects in a
database, and implements one storage backend (a "database" if you will).
other backends are possible and desirable, especially using industrially
proven embedded database systems like BerkeleyDB or SQLite (see section
Future Development [1]).
when you access a persistent object through a locator (see [2]), e.g.
like this:
shared_loc<person> p=...; //note the _loc, not a pointer!
cerr << p->first_name << ' ' << p->last_name << endl;
the locator holds a ResourceManager::object_id, whatever that may be.
the default resource manager uses a couple of files to store the
objects, and ResMgr::object_id is an actual integral object id
identifying the object in those files.
but other resource managers can be implemented. then, ResMgr::object_id
could be a BerkeleyDB key, could be a SQL primary key, or could be a
filename. see [3] and [4] for more info on how to configure the library
and use other resource managers.
on a side note, was there any progress on Boost.Rdb or other proposals
for boost libraries providing SQL interfaces and/or object-relational
mapping?
[1]
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/future.html
[2]
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/access.html#persistent.access.locators
[3]
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/configuring.html#persistent.configuring.defaulttrans
[4]
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/extending.html
[3] and [4] has changed somewhat, since it was moved to another proposed
library, Boost.Transact
Stefan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk