[odb-users] Circular relation problem with external file mapping

[Romain Gros]

Hi Boris,

It was my mistake. After trying to make a simple example of the error, I
saw that I made QuestStep::quest_ (the target of the inverse for
Quest::steps_) transient !
I remove the transient and it's working !

But, I have a problem of loading :
1 - It loads the Quest
2 - It loads the Quest::steps_ container (SELECT `QuestStep`.`idqueststep`
FROM `QuestStep` WHERE `QuestStep`.`idquest`=?)
3 - Then it loads each QuestStep, calling the
container_traits_type::load (SELECT
`QuestStep`.`idquest`,`QuestStep`.`idqueststep`,`QuestStep`.`orderqueststep`
FROM `QuestStep` WHERE `QuestStep`.`idqueststep`=?). But at this point, the
QuestStep::quest_ pointer in the loaded object is not initialized, it's
only a default value.
4 - Then, it calls the sts.load_delayed function. In here, it's like the
step 1: it loads the Quest object, then the container, etc.

Is it normal ? Can I disable the delayed_load for the QuestStep::quest_ ?
Is it possible that, because we copy the content of the virtual container
into the real container Quest::steps_, ODB try to load the object every
time ?

Regards,
Romain


2013/7/27 Boris Kolpackov <boris at codesynthesis.com>

> Hi Romain,
>
> Romain Gros <grosr.romain at gmail.com> writes:
>
> > It seems to be a problem with the protobuf, but have you an idea of what
> > could cause this?
>
> No, that's a bug in the ODB compiler.
>
>
> > Is there a way to launch the ODB compiler in debug, to see where exactly
> > the exception is launched ?
>
> The easiest way is to run the ODB compiler with the -x -dH option. This
> will cause it to dump core which you can then examine with GDB. Note that
> you will need to do it with the cc1plus executable (that's the actual C++
> compiler) that corresponds to g++ used by ODB. You can see where this
> file is located with this command:
>
> g++ -print-file-name=cc1plus
>
> What can be even better is if you could send me a small test case that
> reproduces this problem. Ideally without any ProtoBuffer dependencies
> (i.e., just recreate the structure in your own classes) but if that's
> too difficult, then with ProtoBuffer. I can then take a look and
> hopefully fix this.
>
> Boris
>