[odb-users] Object reference in composite value type

[Boris Kolpackov]

Hi Harald,

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

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

Yes, I thought about it but it is a lot trickier than what may seem.
ODB passes/returns object ids in a lot of places. So there has to be
a single "id type" of some kind. You suggested that the ODB compiler
automatically generate such a type and that was the idea I initially
had. But things start falling apart once you consider relationships
that span multiple header files. The second file needs to somehow
"see" the generated composite id type during ODB compilation. We also
cannot generate two copies and there is no way for ODB to see generated
code from another compilation process. As you can see, things get very
complicated very fast.

So at the moment one has to define a composite value manually. Things
that may alleviate some of the burden are the ability to define a
composite value as a class template instantiations as well as the
ability to define composite values as nested classes inside
persistent classes (Section 7.2, "Composite Value Types").


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

Yes, if there is no regularity in column naming in your schema, then
this can be a bit of an inconvenience.


> I haven't thought this through completely yet but the id pragma
> for multiple members would solve this, I guess.

No, to get the primary key you need to use object pointers. 


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

Actually, the container table doesn't even have a primary key. It
has a foreign key that points back to the containing object. Plus
an index for the sequence containers.

Another approach that you can consider is to define a unique
composite index (using the ODB index pragma). This will be 
semantically equivalent to the primary key.

Boris