[odb-users] Object reference in composite value type

[Harald Frostel]

Hi Boris,
 
> You can use object pointers in composite values. What you are looking
> for is using object pointers in (composite) object ids. This is
> currently not supported though we are planning to support this at
> some point.
 
One very helpful feature would be the ability to specify more than one class member as ID. Than the definition of composite values would be obsolete in a lot of cases (e.g. could be generated by the compiler).
 
One (slightly different) problem I encounter with composite values (object ids) is, that the column names are fixed in a composite value. If an object has a composite primary key with the columns lets say {ID1, ID2} and I reference it with a pointer in another object, this object has to have the column names {ID1, ID2} or {Prefix_ID1, Prefix_ID2}. That is ok, if I create the database schema and objects together but can be difficult if I have to wrap the object model around an existing schema, where the column names are different. Than I have to create a foreign-key-composite value struct and a virtual data member for the referencing class.
 

> You could also go one step further and use a virtual data member
> for parent_id (and a transient pointer member). This way you will
> end up with a single physical data member (pointer) instead of two.
> But yes, the foreign key semantics in the schema is lost with this 
> approach.
 

Right now, I'm actually using the virtual member solution. It works, but yes, the foreign key constraint is lost and I cannot use the reference in a query (e.g. query<ChildObj>::parent_->some_value==x).
I haven't thought this through completely yet but the id pragma for multiple members would solve this, I guess.
 
> The database schema that you are trying to re-create is very similar
> to what one gets when using a container. So you may want to consider
> making your child object actually a (composite) value and then have
> a container of those in the parent object.
 
Yes, that could work. I think I dropped this solution because the generated schema is not exactly the same (ChildID is the only primary key), but I have to check.
 
Regards
Harald
 
 
****************************************************
Dipl.-Ing. Harald Frostel
Department of Computational Perception
Johannes Kepler University Linz
Altenberger Strasse 69
A-4040 Linz, Austria	    
 
Tel:  +43 732 2468 1521
Fax:  +43 732 2468 1520
Mail: harald.frostel at jku.at
http://www.cp.jku.at/people/frostel
****************************************************


>>> Boris Kolpackov <boris at codesynthesis.com> 28.01.2014 05:18 >>>
Hi Harald,

Harald Frostel <Harald.Frostel at jku.at> writes:

> Is there a way to use a shared_ptr/lazy_shared_ptr in a composite
> value?

You can use object pointers in composite values. What you are looking
for is using object pointers in (composite) object ids. This is
currently not supported though we are planning to support this at
some point.

  
> The workaround right now is to use custom set/get methods (replace the
> reference in the composite value by an int parent_id_ and create a
> lazy_pointer of this parent id during loading) for the child object id
> but than, in the generate schema the foreign key relation is lost.

You could also go one step further and use a virtual data member
for parent_id (and a transient pointer member). This way you will
end up with a single physical data member (pointer) instead of two.
But yes, the foreign key semantics in the schema is lost with this
approach.


> Is there a way to solve this differently (without changing the schema
> of the database)?

The database schema that you are trying to re-create is very similar
to what one gets when using a container. So you may want to consider
making your child object actually a (composite) value and then have
a container of those in the parent object.

Boris