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/... [2] https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... [3] https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... [4] https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/... [3] and [4] has changed somewhat, since it was moved to another proposed library, Boost.Transact Stefan