[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