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.
Andrus
> Yeah, it's probably not the best example, but it was what I was given to
> working with. If I'd been the one setting up and naming the tables, it'd
> be SecOrganizationRole, SecGroupRole, and SecRole. SecRole represents a
> privilege set. SecGroup adds hierarchy. Organization is just a
> specialized SecGroup. Let's stick with
> PERSON/CUSTOMER[/INTERNAL_CUSTOMER]
> since it's a clearer example.
>
>> So let's take KODO example at
>>
> http://www.solarmetric.com/Software/Documentation/3.3.3/docs/img/inheritance-
> vertical.png
>>
>> Customer is a subclass of Person, but it is still a single object.
>
> Yes, it's a single object, but it has to represent two java tables (more
> with deeper inheritance hierarchies). To my understanding, that has to be
> handled with two separate DataObjects, one for the PERSON table, and one
> for
> the CUSTOMER table.
>
This archive was generated by hypermail 2.0.0 : Wed Jun 15 2005 - 14:46:39 EDT