[odb-users] Lazy Relationships?

[Boris Kolpackov]

Hi Christian,

Christian Sell <christian at gsvitec.com> writes:

> the duh refers to the fact that a standard load operation which pulls data from
> multiple related tables does not use the obvious SQL optimization meachnisms.
> There may be ways to get the optimized SQL, but I see no reason why they
> shouldn't be employed transparently in the standard case as well.

There are reasons. Firstly, in most non-trivial applications most
relationships will be lazy, at least this is what we advocate.
Secondly, consider a to-many relationship: If you JOIN the 
relationship data to the same SELECT statement, you are going to
fetch N copies of the object. Maybe not a big deal unless N is
large or you have a couple of massive BLOBs in the object. So,
as you can see, this is not as clear cut as you make it sound.
And the "ODB way", in such situations, is not to make any
assumptions and instead give you the mechanisms and control to do
it either way (See the "Object Loading Views" Section for how
to get the behavior that you advocate).


> I am talking about a to-N relationship which is lazily resolved, not
> a pointer (which, in my book, points to one object). Let me know if
> I overlooked something

Say you have:

std::vector<odb::lazy_ptr<object>> objects;

In this setup the object ids for all the pointed-to objects will be
loaded eagerly, but not the objects themselves. To load the objects,
you will have to load them explicitly by calling load() on each 
element (lazy_ptr<object>).

Now, you may want to get even lazier and not even load object ids.
This you can only do by placing 'objects' into a lazy-loaded  section.
In fact, the chapter on sections talks about this two-level laziness.

Boris