[odb-users] polymorphic inheritance, typeid, odb::object_not_persistent

MM finjulhich at gmail.com
Wed Jul 22 11:46:41 EDT 2015


On 22 July 2015 at 15:43, Boris Kolpackov <boris at codesynthesis.com> wrote:

> Hi,
>
> MM <finjulhich at gmail.com> writes:
>
> > Within the same transaction, I do successfully load 11(all) of the
> > 'sometype':
> > I get raw pointers from the load() calls (same as above), and I own these
> > pointers with a boost::ptr_vector.
> > _After_ the 'sometype' are loaded, I, then, load the Base items. But that
> > fails.
>
> What if you try to load D1..D10 using load() rather than query(),
> specifying either Base or the concrete types (both should work).
> This way you can narrow it down to which one fails to load (if
> any; it can also be that load() will work and there is something
> special about query()).
>
>
> > Am I breaking the relationship for odb to connect the dots somehow?
>
> Not that I can see.
>
>
> > Is there some sort of debugging I can trigger to detect the issue?
>
> Yes, in fact, enabling statement tracing in such situations can be
> very helpful. Try:
>
> t.tracer (stderr_tracer);
>
> This way we will at least know where exactly things go south.
>
> Boris
>

The first load succeeds for 'sometype' as mentioned before, and the sql
queries are traced out.

Then, the code that fails:

{
      auto res = db.query<NS::Base>();
      std::size_t cnt = 0u;
      for (auto i=std::begin(res); i!=std::end(res); ++i, ++cnt)
        some_function( i.load() );
      std::cout<<" "<<cnt<<" items loaded" << std::endl;
}

yields these SQL stmts:

SELECT "Base"."name", "Base"."typeid", "Base"."cal" FROM "Base"
SELECT "OtherTable"."name" FROM "OtherTable" WHERE "OtherTable"."name"=?
object not persistent
terminate called after throwing an instance of 'odb::object_not_persistent'
  what():  object not persistent

some of the Base.cal are NULL in the database.

obviously I would need to change my

#pragma db member(Base::cal_) get(&this.sometype())  set(this.sometype
(*(?)))

How to say: if NULL in the database, then don't sent the cal member?


More information about the odb-users mailing list