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

[Romain Gros]

Hi Boris !

Sorry for this little absence, I didn't have a lot of time.

I just implemented the second solution and when I try to compile, I got the
following error message :

terminate called after throwing an instance of
'cutl::compiler::context::no_entry'
  what():  N4cutl8compiler7context8no_entryE

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_START_UNIT                | odb
PLUGIN_PRAGMAS                   | odb
PLUGIN_OVERRIDE_GATE             | odb
In file included from ./include/odb/container-traits.hxx:210:0,
                 from <standard-odb-epilogue>:9:
./include/odb/std-vector-traits.hxx: In destructor 'virtual
google::protobuf::internal::ExtensionSet::LazyMessageExtension::~LazyMessageExtension()':
./include/odb/std-vector-traits.hxx:66:1: internal compiler error: Aborted
Please submit a full bug report, with preprocessed source if appropriate.

It seems to be a problem with the protobuf, but have you an idea of what
could cause this ?
Is there a way to launch the ODB compiler in debug, to see where exactly
the exception is launched ? Because the std-vector-traits.hxx:66 is the end
of the odb namespace, so I can't understand where does this come from !

I still haven't tried the 'value way', because I didn't read a lot about
value for now, but I'll try this later for sure !

Thanks for your help,
Regards


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

> Hi Romain,
>
> Romain Gros <grosr.romain at gmail.com> writes:
>
> > I'll try to make QuestStep a composite value type when I have some time.
> >
> > But we have a lot of object organized like that, because of the protobuf,
> > and I'm not sure we can do this for everything !
>
> This is conceptually the correct way to map it. In ODB, objects are
> independent entities, they are not contained by other objects. In
> contrast, values are always part of some object. Even your vocabulary
> suggest that QuestStep is a value that is part of the Quest object
> (i.e., it is called QuestStep (Quest's Step), not just Step).
>
> You may also want to read Section 3.1, "Concepts and Terminology" for
> more information on this distinction.
>
>
> > Moreover, I really want to learn how your ORM work, so if you have some
> > time to tell me about the other way, I would appreciate knowing it !
>
> The idea is to use lazy pointers and virtual data members to make
> ODB think there is a vector of pointers to objects. The trick is
> then to implement accessors and modifiers in such a way that they
> take object ids from lazy pointers and load the object state
> directly into the "contained" data members. Here is an outline:
>
> struct Quest;
>
> #pragma db object
> struct QuestStep
> {
>   ...
>
>   Quest* quest_;
> };
>
> #pragma db object
> struct Quest
> {
>   ...
>
>   #pragma db transient
>   std::vector<QuestStep> steps_;
>
>   typedef std::vector<odb::lazy_ptr<QuestStep>> QuestStepPointers;
>
>   #pragma db member(steps) virtual(QuestStepPointers) inverse(quest_) \
>              get(steps_value_to_ptr) set(steps_ptr_to_value)
>
>   QuestStepPointers
>   steps_value_to_ptr () const
>   {
>     QuestStepPointers r;
>
>     for (std::vector<QuestStep>::const_iterator i (steps_.begin ());
>          i != steps_.end ();
>          ++i)
>     {
>       // Initialize lazy_ptr with a pointer to steps_ element.
>       //
>       r.push_back (&*i);
>     }
>   }
>
>   void
>   steps_ptr_to_value (const QuestStepPointers& ps)
>   {
>     for (QuestStepPointers::const_iterator i (ps.begin ());
>          i != ps.end ();
>          ++i)
>     {
>       // Load object state directly into steps_ element.
>       //
>       steps_.push_back (QuestStep ());
>       i->database ().load (steps_.back (), i->object_id<QuestStep> ());
>     }
>   }
> };
>
> As you can see, pretty involved but I guess also pretty cool at some
> level. The things one can do with virtual data members keep surprising
> me.
>
> Boris
>