[odb-users] Re: Self persisting objects?

Oded Arbel oded at geek.co.il
Thu Aug 30 12:14:39 EDT 2012


On Thu, Aug 30, 2012 at 4:37 PM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Oded Arbel <oded at geek.co.il> writes:
>> libodb-2.0.1\odb\database.ixx(49): error C2440: 'initializing' :
>> cannot convert from 'model::Employee *' to 'const object_pointer &'
>
> So what most likely happens is you are using a smart pointer [...]

Not in this specific piece of code - its just a "this" pointer. s_db
is a smart pointer though - does it matter?

> [...] So if
> you are not planning to use sessions, then you can instead
> replace:
>
> s_db->persist(this);
>
> With:
>
> s_db->persist(*this);

I changed it as you said and it looks to be working fine now. I'm not
using sessions, but its something that I might want to look into in
the future (possibly as an optimization), and I'm a bit confused
regarding why is there a difference in the behavior of "this"
dereferencing in regard to it being held by a smart pointer or not.

> Just a side note: a better design might be to leave it to the caller
> of Employee::persist() to create the transaction. This way the caller
> will be able to persist several objects at once:
> [...]
> The added benefit of this approach is that you can get the database
> from the current transaction without having to store it in a static
> field or similar:
>
> void Employee::persist() {
>   odb::transaction& t (odb::transaction::current ());
>   odb::database& db (t.database ());
>   db.persist (*this);
> }

That is very interesting - I'll have to consider that in the future,
but in the mean time I'm trying to complete a basic implementation
before doing more complex things :-)

-- 
Oded



More information about the odb-users mailing list