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

Jeff Waller truthset at gmail.com
Sun Jul 28 11:24:49 EDT 2013


Either way, a compiler should never abruptly fail under any circumstances.
so even though it's a programming error, it's still worth sending.


On Jul 27, 2013, at 2:18 PM, Romain Gros wrote:

> 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
>> 




More information about the odb-users mailing list