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.