Re: [boost] persistence library proposal ( with prototypeimplementation )

Subject: Re: [boost] persistence library proposal ( with prototypeimplementation )
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-12 09:31:39

Am Wednesday 12 August 2009 11:18:26 schrieb Vicente Botet Escriba:
>
> Does this means that a persistent object is writen to disk only when a
> db_ptr is reachable while commiting a transaction?

yes. an object only survives a transaction if it is reachable from the 
database root.
see the banking example. there the bank is the database root, and it hold's 
db_ptr's to the individual accounts, so the accounts are reachable and saved 
to disk.
just like you'd expect from a boost::shared_ptr.

>
> The wrapper has the drawback that doesn't define the same interface as the
> type T. So when the smart pointer is dereferenced the result will not
> provides these interface.

why not? the smart pointer would either return a int & or an int const &, 
depending on read or write access.

> > 2.
> > I noticed that in transaction_object, you call the user-supplied
> > operator= of
> > T, accomplishing only a shallow copy of the object.
> > does that mean that:
> >
> > struct A : transaction_object {
> > 	B *b;
> > };
> >
> > A a;
> >
> > write(a)->b->member++; //non-transactional memory?
>
> Whether member is transactional or not depend on whether B inherits from
> transactional_object < B > or not. Anyway you are right, you need to access
> the member b using a transactional smart pointer
>
> wr_ptr< B > tx_a_b(a.b, tx);
> tx_a_b->member++;
>
> Now the update of member will be taken in account by the transaction tx.

I'd reconsider that.

struct A{
        void do(){ a=1; }
        int a;
};
struct B{
        void do(){ *a=1; } //error
        int *a;
}

A and B imho should behave in the same way when used as a transaction object.

If you disagree with that, or if that's impractical for some reason, there is 
really no point in removing the requirement to derive from 
transaction_object.
the implementor of the type must be very aware that he's implementing a 
transaction object anyway, so I'd consider it not a bug but a feature, that 
he must express this intention explicitely by deriving from 
transaction_object.