So I guess we may say that doing it with composite objects is already
possible with Cayenne 1.1 and newer, and can be automated via class
generation. Downside - you need ObjEntities for "nonexistent" classes, but
otherwise it looks pretty clean (uniquing handling and all).
I am not sure if we should add anything to Cayenne for that. Specifying
the composition "path" maybe? I'd rather make this a generic annotation
used by class generator (there is lots of unrelated requests to support
arbitrary annotations of the DataMap for customization ... this is a good
occasion to put it in).
Also I agree that doing the "transparent" vertical inheritance maybe lots
of work... but this is work to support flattened atributes really, nothing
beyond that. And there will be no need to select "type" of inheritance, as
it will work just like the single table variety.
So Mike, do you think we'll get your project requirements addressed by the
quick composition solution (with class generator and model annotations),
and then do the right thing with flattened attributes, even if it takes
more time?
Andrus
> Andrus Adamchik <andru..bjectstyle.org> wrote:
>> I see... No, my plan was to keep a single object with properties coming
>> from the joined tables being indistinguishable from the properties
>> coming
>> from the root table.
>>
>> So on the Java end this will look like "vanilla" OO inheritance
>> (implying
>> that there will be a single ObjectId). It would be the responsibility of
>> Cayenne to build all needed joins when doing a select and building
>> multiple insert/update/delete queries on commit.
>
> That sounds pretty neat. It also sounds like a lot of work. :)
>
> I know Michael is currently doing it with composite objects, and I was in
> the process of doing it with composite objects. It's unclear to me how
> other ORM systems handle this.
>
> One advantage of a composite approach is that there's no uniquing problem
> since each table record exists as a separate object. Is that also true
> with
> cayenne handling everything?
>
> So here's my plan of attack.
>
> #1) extend DataMap / the datamap xml file to support vertical inheritance
> attributes:
>
> - add a type-of-inheritance attribute
> - add a KODO-like ref-column.<pk column> to the entity, or add an
> attribute
> to ObjRelationships to mark it as the path to the inherited parent record.
> I originally thought this could be derived from to-Dep-PK && !isToMany,
> but
> that's probably too restrictive.
>
> #2) flattened attributes (by extending ObjEntity?)
> #3) get select working
> #4) get the rest working?
>
>
> Also, just so this fact gets recorded somewhere (since I figured this out
> while researching), Hibernate uses different nomenclature:
>
> flat/single-table inheritance = table per class hierarchy
> vertical inheritance = table per subclass
> horizontal inheritance = table per concrete class
>
> http://www.hibernate.org/hib_docs/v3/reference/en/html/inheritance.html
>
This archive was generated by hypermail 2.0.0 : Wed Jun 15 2005 - 16:19:05 EDT