[odb-users] Usage of lazy shared pointers in a triangle relation

Quentin Deldycke quentindeldycke at gmail.com
Thu Oct 23 03:33:34 EDT 2014

Hi Boris,


Quentin Deldycke
Le 23 oct. 2014 07:41, "Boris Kolpackov" <boris at codesynthesis.com> a écrit :

> Hi Quentin,
> Quentin Deldycke <quentindeldycke at gmail.com> writes:
> > I have a problem using this kind of architecture:
> >
> > - class A have a lazy_shared_pointer to C
> > - class B have a lazy_shared_pointer to another C
> > - class C contains a int
> >
> > In my mysql database, we can easily see that our class A
> > is linked to a class C with value '1' and my class 'B' is linked
> > to a class C with value '2'.
> >
> > In my code, I query all class A, for each A, we query for objects B.
> > For each B I print values of A, B and the class C of both of them.
> I am not sure what "for each A, we query for objects B" means since
> from your description above they seem to be unrelated.
> We query A using some fields local to the class.
Depending of these results, we query B using fields local to this class.

Then we compare the internal C class of both A and B.

> > Strangely, I have only output of C == '2'.
> >
> > I then tried to compare the pointer of both C object stored in A and B.
> > I found that they are the same! So for each loop on objects B, the value
> of
> > A->C is updated to values of B->C.
> I can't think of any reason why this would happen other than if both C's
> had the same primary key. So I would need to see the actual code that
> does the query. Actual class declarations could also be helpful. What
> happens if you print the value of A-C before you "query for objects B"?
> Yes. The output of A->C is correct before the query of B.

Ok, this give me the correct intptr_t to the problem. During our calculation
between both our C classes, we made an assignation between both (B->C =
As expected, in C++, it copied the whole shared_ptr and not the pointed to
object values
(as expected in our developper head).

Thanks for your  help!

> > Do you have any int to avoid this problem?
> int64_t helps with all kinds of problems ;-)
> Boris

More information about the odb-users mailing list