You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@maniatis.org> on 2007/06/01 01:37:41 UTC
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
On 01/06/2007, at 2:26 AM, Mike Kienenberger wrote:
> You might want to grab some of the info on
>
> http://cwiki.apache.org/confluence/display/CAY/Is+Inheritance
> +Supported
>
> and merge it into your new document.
>
> I'm thinking specifically about the additional names by which
> vertical, horizontal, and single inheritance are known by. This
> makes it easier for folks coming in from an ORM where the terminology
> is different.
Is that terminology right? That page says:
* single-table == flat == table-per-class-hierarchy
* Vertical == table-per-subclass
* Horizontal == table-per-concrete-class
My page says:
* single-table
* horizontal == table-per-class
* vertical == joined
I don't see how table-per-class can be used to describe single-table
inheritance, since there isn't a table per class. Just one table. And
vertical isn't table per subclass, it also has another table.
Finally, there is no reason the horizontal superclass can't be concrete.
If anything, horizontal should be described as 'table-per-subclass'.
The terminology is very important I agree, but do you have any
references for those terms, so that we can use the what people will
be expecting to see? The main references we've been looking at are
the JPA docs, Hibernate and WO docs.
Cheers
Ari
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Mike Kienenberger <mk...@gmail.com>.
It may be wrongly named (to our eyes), but that's what Hibernate was
calling it. (Some of these may have also come from Toplink as well).
If it makes you feel better call it "Hibernate table-per-subclass" and so on.
On 5/31/07, Lachlan Deck <la...@gmail.com> wrote:
> On 01/06/2007, at 9:37 AM, Aristedes Maniatis wrote:
>
> > Is that terminology right? That page says:
> >
> > * single-table == flat == table-per-class-hierarchy
>
> Easily true.
>
> > * Vertical == table-per-subclass
>
> That is wrongly named. That is horizontal inheritance where the
> parent doesn't map to a table. Vertical involves parent and kids each
> having their own table. (See http://developer.apple.com/documentation/
> WebObjects/UsingEOModeler/index.html as an example)
>
> > * Horizontal == table-per-concrete-class
>
> Correct, though hazy terminology for mine seeing as vertical also has
> a table for the parent.
>
> The JPA for better or worse has:
> - Inheritance.SINGLE_TABLE. That's the easy one.
> - Inheritance.JOINED. Most definitely == vertical.
> - Inheritance.TABLE_PER_CLASS. This is (for mine anyway) an unclear
> name given that JOINED is also a table per class. It would have been
> clearer if they'd chosen TABLE_PER_SUBCLASS.
>
> > My page says:
> >
> > * single-table
> > * horizontal == table-per-class
> > * vertical == joined
>
> That is correct.
>
> From the JPA:
>
> Joined: A strategy in which fields that are specific to a subclass
> are mapped to a separate table than the fields that are common to the
> parent class, and a join is performed to instantiate the subclass.
>
> Table-per-class: A table per concrete entity class.
>
> As additional support for this... see also description here (http://
> java.sys-con.com/read/286901.htm) which documents them a little more
> verbosely as:
>
> SINGLE_TABLE: Single-table-per-class inheritance hierarchy. This is
> the default strategy. The entity hierarchy is essentially flattened
> into the sum of its fields, and these fields are mapped down to a
> single table.
>
> JOINED: Common base table, with joined subclass tables. In this
> approach, each entity in the hierarchy maps to its own dedicated
> table that maps only the fields declared on that entity. The root
> entity in the hierarchy is known as the base table, and the tables
> for all other entities in the hierarchy join with the base table.
>
> TABLE_PER_CLASS: Single-table-per-outermost concrete entity class.
> This strategy maps each leaf (i.e., outermost, concrete) entity to
> its own dedicated table. Each such leaf entity branch is flattened,
> combining its declared fields with the declared fields on all of its
> super-entities, and the sum of these fields is mapped onto its table.
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Lachlan Deck <la...@gmail.com>.
On 01/06/2007, at 9:37 AM, Aristedes Maniatis wrote:
> Is that terminology right? That page says:
>
> * single-table == flat == table-per-class-hierarchy
Easily true.
> * Vertical == table-per-subclass
That is wrongly named. That is horizontal inheritance where the
parent doesn't map to a table. Vertical involves parent and kids each
having their own table. (See http://developer.apple.com/documentation/
WebObjects/UsingEOModeler/index.html as an example)
> * Horizontal == table-per-concrete-class
Correct, though hazy terminology for mine seeing as vertical also has
a table for the parent.
The JPA for better or worse has:
- Inheritance.SINGLE_TABLE. That's the easy one.
- Inheritance.JOINED. Most definitely == vertical.
- Inheritance.TABLE_PER_CLASS. This is (for mine anyway) an unclear
name given that JOINED is also a table per class. It would have been
clearer if they'd chosen TABLE_PER_SUBCLASS.
> My page says:
>
> * single-table
> * horizontal == table-per-class
> * vertical == joined
That is correct.
From the JPA:
Joined: A strategy in which fields that are specific to a subclass
are mapped to a separate table than the fields that are common to the
parent class, and a join is performed to instantiate the subclass.
Table-per-class: A table per concrete entity class.
As additional support for this... see also description here (http://
java.sys-con.com/read/286901.htm) which documents them a little more
verbosely as:
SINGLE_TABLE: Single-table-per-class inheritance hierarchy. This is
the default strategy. The entity hierarchy is essentially flattened
into the sum of its fields, and these fields are mapped down to a
single table.
JOINED: Common base table, with joined subclass tables. In this
approach, each entity in the hierarchy maps to its own dedicated
table that maps only the fields declared on that entity. The root
entity in the hierarchy is known as the base table, and the tables
for all other entities in the hierarchy join with the base table.
TABLE_PER_CLASS: Single-table-per-outermost concrete entity class.
This strategy maps each leaf (i.e., outermost, concrete) entity to
its own dedicated table. Each such leaf entity branch is flattened,
combining its declared fields with the declared fields on all of its
super-entities, and the sum of these fields is mapped onto its table.
with regards,
--
Lachlan Deck
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Lachlan Deck <la...@gmail.com>.
On 03/06/2007, at 6:50 PM, Andrus Adamchik wrote:
> One note - in Cayenne discriminator column is implemented via a
> more generic entity qualifier expression (e.g. it can match
> multiple columns or use some custom comparison condition). This
> approach generally prevents a simplification of a mandatory
> discriminator column on a root class, although we may actually work
> around it and start by implementing a simplified case (i.e. support
> entity qualifiers in the form "attribute = constant" on all
> subentities).
>
> I am still entertaining the idea that we can support vertical
> inheritance without a designator column, and I don't think that
> having such column in place is such a big shortcut in
> implementation. After all the logic will be the same as with
> horizontal inheritance - sublcass criteria is an existence of a row
> in the subclass table).
My understanding of the need for a discriminator column (from eof) is
- it's only necessary if the parent is not abstract, and
- you plan on fetching/instantiating the parent without needing to
fetch the characteristics of the sub-entities so as to distinguish them.
That seems to lend itself to utilising the current single-table
implementation where such a column is used.
How do you envisage this working otherwise?
with regards,
--
Lachlan Deck
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Andrus Adamchik <an...@objectstyle.org>.
Correct. "Abstract" and "lazy resolution" (and also various fetch/
instantiation strategies) are unrelated concepts.
Andrus
On Jun 4, 2007, at 3:19 AM, Lachlan Deck wrote:
> On 04/06/2007, at 7:19 AM, Lachlan Deck wrote:
>
>> On 04/06/2007, at 6:40 AM, Lachlan Deck wrote:
>>
>>> On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
>>>
>>>> 2. Fetching only the base table on select should be possible, so
>>>> that's probably the most obvious benefit. Originally I thought
>>>> in this case users would always want to fetch the full objects,
>>>> and this buys us nothing, but from the earlier emails by
>>>> Lachlan, there may often be a need to iterate through just the
>>>> superclass attributes. Lazy fetching of subclass table may be a
>>>> better solution to that, compared to the one suggested before -
>>>> instantiating superclass objects, ignoring the correct class.
>>>
>>> Hmm. That would be nice actually and would certainly simplify any
>>> dealings with the global id. However, that may pose other
>>> problems with PostLoad(?) whereby some code that you might
>>> normally performed on PostLoad of a sub-entity may not be desired
>>> to be run when just fetching the parent. How would you
>>> discriminate between the two situations?
>>>
>>> But taking a step back, if you're suggesting that the parent can
>>> only ever be treated as abstract then the feature request for
>>> isAbstract won't make sense anymore.
>
> Woops. Disregard this statement. Momentary confusion of concepts ;-)
>
>>> It wouldn't make sense to allow a parent to be abstract but yet
>>> never actually be capable of being instantiated. For me, I think
>>> this is a problem for the individual application to work out. By
>>> having the discriminator column you've allowed the parent to be
>>> instantiated whilst maintaining the correct global id haven't you?
>>
>> Let me clarify that further by saying that I don't think it's
>> correct to allow the creation of parent entities and then later
>> morphing them into some sub-type. I'm only thinking of allowing
>> the instantiating of parent entities for the purposes of fetching/
>> performance considerations.
>
> And further clarifying that again - of course it's perfectly okay
> to create a persistent Person, for example, that is always a
> concrete Person. That's where I think the discriminator column
> comes into play when allowing the parent to be non-abstract...
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Lachlan Deck <la...@gmail.com>.
On 04/06/2007, at 7:19 AM, Lachlan Deck wrote:
> On 04/06/2007, at 6:40 AM, Lachlan Deck wrote:
>
>> On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
>>
>>> 2. Fetching only the base table on select should be possible, so
>>> that's probably the most obvious benefit. Originally I thought in
>>> this case users would always want to fetch the full objects, and
>>> this buys us nothing, but from the earlier emails by Lachlan,
>>> there may often be a need to iterate through just the superclass
>>> attributes. Lazy fetching of subclass table may be a better
>>> solution to that, compared to the one suggested before -
>>> instantiating superclass objects, ignoring the correct class.
>>
>> Hmm. That would be nice actually and would certainly simplify any
>> dealings with the global id. However, that may pose other problems
>> with PostLoad(?) whereby some code that you might normally
>> performed on PostLoad of a sub-entity may not be desired to be run
>> when just fetching the parent. How would you discriminate between
>> the two situations?
>>
>> But taking a step back, if you're suggesting that the parent can
>> only ever be treated as abstract then the feature request for
>> isAbstract won't make sense anymore.
Woops. Disregard this statement. Momentary confusion of concepts ;-)
>> It wouldn't make sense to allow a parent to be abstract but yet
>> never actually be capable of being instantiated. For me, I think
>> this is a problem for the individual application to work out. By
>> having the discriminator column you've allowed the parent to be
>> instantiated whilst maintaining the correct global id haven't you?
>
> Let me clarify that further by saying that I don't think it's
> correct to allow the creation of parent entities and then later
> morphing them into some sub-type. I'm only thinking of allowing the
> instantiating of parent entities for the purposes of fetching/
> performance considerations.
And further clarifying that again - of course it's perfectly okay to
create a persistent Person, for example, that is always a concrete
Person. That's where I think the discriminator column comes into play
when allowing the parent to be non-abstract...
with regards,
--
Lachlan Deck
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Lachlan Deck <la...@gmail.com>.
On 04/06/2007, at 6:40 AM, Lachlan Deck wrote:
> On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
>
>> On Jun 3, 2007, at 2:44 PM, Craig L Russell wrote:
>>
>>>> I am still entertaining the idea that we can support vertical
>>>> inheritance without a designator column, and I don't think that
>>>> having such column in place is such a big shortcut in
>>>> implementation. After all the logic will be the same as with
>>>> horizontal inheritance - sublcass criteria is an existence of a
>>>> row in the subclass table).
>>>
>>> The big win here is in performance. If you don't need the
>>> subclass values but need to know the subclass, then the
>>> discriminator allows you to instantiate the right class without a
>>> join.
>>
>> I omitted performance considerations from my previous email, as I
>> wanted to do some analysis of specific cases first. I can think of
>> two typical cases where this may apply:
>>
>> 1. Inferring the object class of a target of to-one relationship
>> to a superclass will NOT be possible just by looking at FK, unless
>> a discriminator column is also a part of the target PK (and source
>> FK). So no DB trip savings in resolving relationships.
>>
>> 2. Fetching only the base table on select should be possible, so
>> that's probably the most obvious benefit. Originally I thought in
>> this case users would always want to fetch the full objects, and
>> this buys us nothing, but from the earlier emails by Lachlan,
>> there may often be a need to iterate through just the superclass
>> attributes. Lazy fetching of subclass table may be a better
>> solution to that, compared to the one suggested before -
>> instantiating superclass objects, ignoring the correct class.
>
> Hmm. That would be nice actually and would certainly simplify any
> dealings with the global id. However, that may pose other problems
> with PostLoad(?) whereby some code that you might normally
> performed on PostLoad of a sub-entity may not be desired to be run
> when just fetching the parent. How would you discriminate between
> the two situations?
>
> But taking a step back, if you're suggesting that the parent can
> only ever be treated as abstract then the feature request for
> isAbstract won't make sense anymore. It wouldn't make sense to
> allow a parent to be abstract but yet never actually be capable of
> being instantiated. For me, I think this is a problem for the
> individual application to work out. By having the discriminator
> column you've allowed the parent to be instantiated whilst
> maintaining the correct global id haven't you?
Let me clarify that further by saying that I don't think it's correct
to allow the creation of parent entities and then later morphing them
into some sub-type. I'm only thinking of allowing the instantiating
of parent entities for the purposes of fetching/performance
considerations.
>> So... considering item #2, we need to give user the flexibility to
>> do lazy vs. eager fetch of multi-table inheritance hierarchies.
>> Wonder if overriding "setResolvingInheritance" flag to handle this
>> is appropriate, or we should handle it as another case of
>> "prefetching a relationship", only this time a DbRelationship that
>> defines the inheritance?
>
> Yes, but my thinking on this was that the determinant for resolving
> inheritance would depend on isAbstract but if isAbstract was to go
> away, how would this work?
with regards,
--
Lachlan Deck
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Lachlan Deck <la...@gmail.com>.
On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
> On Jun 3, 2007, at 2:44 PM, Craig L Russell wrote:
>
>>> I am still entertaining the idea that we can support vertical
>>> inheritance without a designator column, and I don't think that
>>> having such column in place is such a big shortcut in
>>> implementation. After all the logic will be the same as with
>>> horizontal inheritance - sublcass criteria is an existence of a
>>> row in the subclass table).
>>
>> The big win here is in performance. If you don't need the subclass
>> values but need to know the subclass, then the discriminator
>> allows you to instantiate the right class without a join.
>
> I omitted performance considerations from my previous email, as I
> wanted to do some analysis of specific cases first. I can think of
> two typical cases where this may apply:
>
> 1. Inferring the object class of a target of to-one relationship to
> a superclass will NOT be possible just by looking at FK, unless a
> discriminator column is also a part of the target PK (and source
> FK). So no DB trip savings in resolving relationships.
>
> 2. Fetching only the base table on select should be possible, so
> that's probably the most obvious benefit. Originally I thought in
> this case users would always want to fetch the full objects, and
> this buys us nothing, but from the earlier emails by Lachlan, there
> may often be a need to iterate through just the superclass
> attributes. Lazy fetching of subclass table may be a better
> solution to that, compared to the one suggested before -
> instantiating superclass objects, ignoring the correct class.
Hmm. That would be nice actually and would certainly simplify any
dealings with the global id. However, that may pose other problems
with PostLoad(?) whereby some code that you might normally performed
on PostLoad of a sub-entity may not be desired to be run when just
fetching the parent. How would you discriminate between the two
situations?
But taking a step back, if you're suggesting that the parent can only
ever be treated as abstract then the feature request for isAbstract
won't make sense anymore. It wouldn't make sense to allow a parent to
be abstract but yet never actually be capable of being instantiated.
For me, I think this is a problem for the individual application to
work out. By having the discriminator column you've allowed the
parent to be instantiated whilst maintaining the correct global id
haven't you?
> So... considering item #2, we need to give user the flexibility to
> do lazy vs. eager fetch of multi-table inheritance hierarchies.
> Wonder if overriding "setResolvingInheritance" flag to handle this
> is appropriate, or we should handle it as another case of
> "prefetching a relationship", only this time a DbRelationship that
> defines the inheritance?
Yes, but my thinking on this was that the determinant for resolving
inheritance would depend on isAbstract but if isAbstract was to go
away, how would this work?
with regards,
--
Lachlan Deck
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 3, 2007, at 2:44 PM, Craig L Russell wrote:
>>
>> I am still entertaining the idea that we can support vertical
>> inheritance without a designator column, and I don't think that
>> having such column in place is such a big shortcut in
>> implementation. After all the logic will be the same as with
>> horizontal inheritance - sublcass criteria is an existence of a
>> row in the subclass table).
>
> The big win here is in performance. If you don't need the subclass
> values but need to know the subclass, then the discriminator allows
> you to instantiate the right class without a join.
Hi Craig,
I omitted performance considerations from my previous email, as I
wanted to do some analysis of specific cases first. I can think of
two typical cases where this may apply:
1. Inferring the object class of a target of to-one relationship to a
superclass will NOT be possible just by looking at FK, unless a
discriminator column is also a part of the target PK (and source FK).
So no DB trip savings in resolving relationships.
2. Fetching only the base table on select should be possible, so
that's probably the most obvious benefit. Originally I thought in
this case users would always want to fetch the full objects, and this
buys us nothing, but from the earlier emails by Lachlan, there may
often be a need to iterate through just the superclass attributes.
Lazy fetching of subclass table may be a better solution to that,
compared to the one suggested before - instantiating superclass
objects, ignoring the correct class.
So... considering item #2, we need to give user the flexibility to do
lazy vs. eager fetch of multi-table inheritance hierarchies. Wonder
if overriding "setResolvingInheritance" flag to handle this is
appropriate, or we should handle it as another case of "prefetching a
relationship", only this time a DbRelationship that defines the
inheritance?
Andrus
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page
created)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Andrus,
On Jun 3, 2007, at 1:50 AM, Andrus Adamchik wrote:
>
> On Jun 3, 2007, at 2:00 AM, Craig L Russell wrote:
>
>> I hope this doesn't confuse things more, but in reality, you often
>> have schema that fall into multiple categories of mapping.
>
> No confusion at all - in reality we do have to deal with mixed
> scenarios, so we have to account for them.
>
>> For example, a hierarchy might have a table that maps all of the
>> fields of the superclass A. Class B extends A and has a table BS
>> containing a discriminator column WHICHB and the fields of all of
>> the subclasses of B. Another class C extends A and its table C
>> maps only the fields of class C while subclasses C1 and C2 each
>> have their own table for their fields.
>>
>> To make it easier on the ORM, table A might also include a
>> discriminator column WHICHA that explicitly identifies the class
>> that the row corresponds to.
>
> One note - in Cayenne discriminator column is implemented via a
> more generic entity qualifier expression (e.g. it can match
> multiple columns or use some custom comparison condition). This
> approach generally prevents a simplification of a mandatory
> discriminator column on a root class, although we may actually work
> around it and start by implementing a simplified case (i.e. support
> entity qualifiers in the form "attribute = constant" on all
> subentities).
I've also implemented the entity qualifier expression, and you are
right; it's much more generic. However, it's also nice for ease of
use for the user to simply tell you that there is a discriminator
column and specify the values for each subclass.
>
> I am still entertaining the idea that we can support vertical
> inheritance without a designator column, and I don't think that
> having such column in place is such a big shortcut in
> implementation. After all the logic will be the same as with
> horizontal inheritance - sublcass criteria is an existence of a row
> in the subclass table).
The big win here is in performance. If you don't need the subclass
values but need to know the subclass, then the discriminator allows
you to instantiate the right class without a join.
Craig
>
> Andrus
>
>
>
>
>
>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 3, 2007, at 2:00 AM, Craig L Russell wrote:
> I hope this doesn't confuse things more, but in reality, you often
> have schema that fall into multiple categories of mapping.
No confusion at all - in reality we do have to deal with mixed
scenarios, so we have to account for them.
> For example, a hierarchy might have a table that maps all of the
> fields of the superclass A. Class B extends A and has a table BS
> containing a discriminator column WHICHB and the fields of all of
> the subclasses of B. Another class C extends A and its table C maps
> only the fields of class C while subclasses C1 and C2 each have
> their own table for their fields.
>
> To make it easier on the ORM, table A might also include a
> discriminator column WHICHA that explicitly identifies the class
> that the row corresponds to.
One note - in Cayenne discriminator column is implemented via a more
generic entity qualifier expression (e.g. it can match multiple
columns or use some custom comparison condition). This approach
generally prevents a simplification of a mandatory discriminator
column on a root class, although we may actually work around it and
start by implementing a simplified case (i.e. support entity
qualifiers in the form "attribute = constant" on all subentities).
I am still entertaining the idea that we can support vertical
inheritance without a designator column, and I don't think that
having such column in place is such a big shortcut in implementation.
After all the logic will be the same as with horizontal inheritance -
sublcass criteria is an existence of a row in the subclass table).
Andrus
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page
created)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ari,
I hope this doesn't confuse things more, but in reality, you often
have schema that fall into multiple categories of mapping.
For example, a hierarchy might have a table that maps all of the
fields of the superclass A. Class B extends A and has a table BS
containing a discriminator column WHICHB and the fields of all of the
subclasses of B. Another class C extends A and its table C maps only
the fields of class C while subclasses C1 and C2 each have their own
table for their fields.
To make it easier on the ORM, table A might also include a
discriminator column WHICHA that explicitly identifies the class that
the row corresponds to.
Craig
On Jun 2, 2007, at 3:53 PM, Aristedes Maniatis wrote:
>
> On 03/06/2007, at 3:25 AM, Kevin Menard wrote:
>
>> I think what you may have missed is that it's a single
>> table-per-class-hierarchy, not table-per-class.
>
> Yes, you are right. I read it as (table-per-class)-hierarchy rather
> than table-per-(class-hierarchy).
>
> I've made a little translation table for the docs to help users
> coming from Hibernate/WO/JPA. Personally I far prefer the vertical/
> horizontal/single-table naming since it is nicely evocative of the
> diagram.
>
> Ari
>
>
>
>
> -------------------------->
> Aristedes Maniatis
> phone +61 2 9660 9700
> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 03/06/2007, at 6:29 PM, Andrus Adamchik wrote:
> Coming late again into this discussion. Just had a chance to go
> through the page. Really impressed with graphical demonstration of
> ORM inheritance concepts.
Great. I think this is an area with so many terms and acronyms that
it is important to be really clear.
> A few comments:
>
> * As was suggested before, should we keep the interfaces discussion
> separate? There's much more uncertainly about mapping ORM
> interfaces. So maybe create the Interfaces page under CAY space
> that is a scratch space and doesn't get published to the main site?
Sure. Happy to just pull that from the page, or else leave a comment
along the lines of "inheritance may work better in some
circumstances... please see..."
> * Regarding inheritance terminology... I suggest adding a "Cayenne"
> column in the terminology matrix to make clear what we call it in
> Cayenne compared to the other ORM frameworks.
Yes. I was going to, then I realised that perhaps I shouldn't make
that decision on my own. :-)
> * This also begs a question which terminology we adopt, EOF or JPA?
> I am slightly in favor of JPA, as it is more descriptive in the
> absence of the diagram. But historically we used terms "vertical"
> and "horizontal" in the Cayenne community to discuss these
> concepts, so there's an precedent that favors EOF terms. Thoughts?
I am 1000% in favour of the WO terms. Reasons:
1. Simpler, less confronting names and evocative of the diagrams
which are easier to understand than paragraphs of text.
2. I may not be the only person initially confused by the term "table-
per-class-hierarchy" for single table.
3. IMO both Hibernate is wrong with respect to horizontal: we've
discussed it before and I think there is no reason why horizontal
requires the superclass to be mapped as abstract in every case. Sure
it is simpler and more often what is required, but we are writing an
enterprise tool and it should not impose artificial limitations, even
if Hibernate has decided to do that.
4. IMO the JPA is misleading with respect to 'table per class'. There
isn't a table for the superclass. Perhaps if it said 'table per
subclass' that would be more helpful, but that just confuses it with
(5):
5. 'table-per-subclass' just doesn't tell us much with respect to the
Hibernate terminology for vertical. How is that different to the
description of horizontal?
6. The JPA description "joined" does make sense. Well, it does to us
and to anyone who understands what is going on. But at first glance,
to someone who doesn't yet understand how the mapping works, it isn't
immediately obvious and isn't helpful. You may as well refer to
'single table' as the 'discriminator' type - it tells you about how
it works rather than how the tables are laid out.
Also, as a matter of description, I personally far prefer using
realistic tables in the documentation (I've gone with Person,
Teacher, Student). I find reading documentation full of "class A, B,
C" gets really confusing about 5 paragraphs in. The only thing worse
is that dreadful circle, square, shape thing - I mean who has ever
written a java application with a Circle class?
Ari
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Andrus Adamchik <an...@objectstyle.org>.
Coming late again into this discussion. Just had a chance to go
through the page. Really impressed with graphical demonstration of
ORM inheritance concepts.
A few comments:
* As was suggested before, should we keep the interfaces discussion
separate? There's much more uncertainly about mapping ORM interfaces.
So maybe create the Interfaces page under CAY space that is a scratch
space and doesn't get published to the main site?
* Regarding inheritance terminology... I suggest adding a "Cayenne"
column in the terminology matrix to make clear what we call it in
Cayenne compared to the other ORM frameworks.
* This also begs a question which terminology we adopt, EOF or JPA? I
am slightly in favor of JPA, as it is more descriptive in the absence
of the diagram. But historically we used terms "vertical" and
"horizontal" in the Cayenne community to discuss these concepts, so
there's an precedent that favors EOF terms. Thoughts?
Andrus
On Jun 3, 2007, at 1:53 AM, Aristedes Maniatis wrote:
>
> On 03/06/2007, at 3:25 AM, Kevin Menard wrote:
>
>> I think what you may have missed is that it's a single
>> table-per-class-hierarchy, not table-per-class.
>
> Yes, you are right. I read it as (table-per-class)-hierarchy rather
> than table-per-(class-hierarchy).
>
> I've made a little translation table for the docs to help users
> coming from Hibernate/WO/JPA. Personally I far prefer the vertical/
> horizontal/single-table naming since it is nicely evocative of the
> diagram.
>
> Ari
>
>
>
>
> -------------------------->
> Aristedes Maniatis
> phone +61 2 9660 9700
> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 03/06/2007, at 3:25 AM, Kevin Menard wrote:
> I think what you may have missed is that it's a single
> table-per-class-hierarchy, not table-per-class.
Yes, you are right. I read it as (table-per-class)-hierarchy rather
than table-per-(class-hierarchy).
I've made a little translation table for the docs to help users
coming from Hibernate/WO/JPA. Personally I far prefer the vertical/
horizontal/single-table naming since it is nicely evocative of the
diagram.
Ari
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
RE: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Kevin Menard <km...@servprise.com>.
Hi Ari,
> -----Original Message-----
> From: Aristedes Maniatis [mailto:ari@maniatis.org]
> Sent: Thursday, May 31, 2007 7:38 PM
> To: dev@cayenne.apache.org
> Subject: Re: [CONF] Apache Cayenne Documentation: Inheritance
> overview (page created)
>
> I don't see how table-per-class can be used to describe
> single-table inheritance, since there isn't a table per
> class. Just one table.
I think what you may have missed is that it's a single
table-per-class-hierarchy, not table-per-class.
--
Kevin
Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)
Posted by Mike Kienenberger <mk...@gmail.com>.
At the time, those were the terms used by Hibernate and supplied by a
Hibernate user.
I'm pretty sure I double-checked them, but I could be wrong.
On 5/31/07, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
> On 01/06/2007, at 2:26 AM, Mike Kienenberger wrote:
>
> > You might want to grab some of the info on
> >
> > http://cwiki.apache.org/confluence/display/CAY/Is+Inheritance
> > +Supported
> >
> > and merge it into your new document.
> >
> > I'm thinking specifically about the additional names by which
> > vertical, horizontal, and single inheritance are known by. This
> > makes it easier for folks coming in from an ORM where the terminology
> > is different.
>
> Is that terminology right? That page says:
>
> * single-table == flat == table-per-class-hierarchy
> * Vertical == table-per-subclass
> * Horizontal == table-per-concrete-class
>
> My page says:
>
> * single-table
> * horizontal == table-per-class
> * vertical == joined
>
> I don't see how table-per-class can be used to describe single-table
> inheritance, since there isn't a table per class. Just one table. And
> vertical isn't table per subclass, it also has another table.
> Finally, there is no reason the horizontal superclass can't be concrete.
>
> If anything, horizontal should be described as 'table-per-subclass'.
>
> The terminology is very important I agree, but do you have any
> references for those terms, so that we can use the what people will
> be expecting to see? The main references we've been looking at are
> the JPA docs, Hibernate and WO docs.
>
>
> Cheers
> Ari
>
>
> -------------------------->
> Aristedes Maniatis
> phone +61 2 9660 9700
> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
>
>
>
>