Re: [boost] [rdb] rdb/persistent integration

Subject: Re: [boost] [rdb] rdb/persistent integration
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-10-03 21:09:11

Am Sunday 04 October 2009 01:27:32 schrieben Sie:
> So currently you do all the binding to the db yourself ? Which one do
> you use ? What kind of mapping do you plan to support ? Vertical,
> filtered, horizontal, or let the user decide ? Does your tool create the
> tables (typical for object-relational mappers) or does it "objectify" an
> existing database (what I call "relational-object mapping") ?

my library doesn't do o-r-mapping. it started out as a library that lets you 
transparently store objects with an interface as close as possible to using 
objects in memory.
it doesn't use an external DB but handles all storage and transaction issues 
itself. one could call it an object database, but I generally don't, since 
from a "database" you'd expect a few more things, like a query language etc.

that's what it was until I started making the internals more generic so you 
can plug in other backends at different points. one of those points is using 
a different ResourceManager with the interface shown, so you could e.g. 
implement one that stores the objects mapped to tables in a RDBMS, instead of 
my database files.

>
> One of the many problems with ORM in presence of transactions is that
> you (probably) have a table that maps between persistent objects and
> object ids. If new objects are persisted in a transaction and the
> transaction is rolled back, the map must be rolled back too...

in my own implementation of a resource manager there are indeed object ids, 
but this is up to the implementation of the resource manager.
object ids are not exposed to the user but abstracted by what I call 
a "locator".
it resembles the concept of a pointer: a locator describes an 
object "somewhere", either in memory, in a file on disk, or mapped in a 
RDBMS. when a locator is dereferenced, it moves the object to memory and 
returns a pointer to it.
so object ids are hidden from the user and the implementation of the resource 
manager (or storage engine) can choose how to store objects, and how to 
assign ids, as well as the type of mapping, like vertical etc.
I have not implemented any o-r mapping so far.

e.g. linked list of db objects:

shared_loc<node> current=...;
transaction tx;
while(current){
  current->value++;
  current=current->next;
}
tx.commit();

shared_loc::operator-> in this example would eventually call get_instance() in 
the resource manager interface in my last email to obtain an actual object 
instance for the user to read and modify.
how this object is obtained is up to the resource manager implementation, in 
this case an o-r mapper.
most of my library is stuff to accomplish transactional object storage without 
a RDBMS backend, so implementing another resource manager is like replacing 
half my library, so you might wonder what's the benefit of integrating the 
two, besides reusing a few smart pointers and transaction objects.

but I still think it's good abstraction. when I'm finished with the 
generalization you can replace one backend with another with a few typedefs, 
so you could develop a prototype of an app using my object storage backend 
and then define the mappings and move to a RDBMS without any changes to the 
code.
also, you could use more than one resource managers at a time, so you could 
have distributed transactions between two databases, between a file and a 
database, etc., and can have references across resources. (a locator can 
reference an object in any resource, and can be stored as part of an object)

I have some documentation ready, but it still refers to the state of the 
library when there was no way to exchange the components to support other 
backends. most of the code is in this stage, too, the generalization is in 
its early stages.