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 - 15:52:18 EDT