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
This archive was generated by hypermail 2.0.0 : Sun Jun 03 2007 - 05:03:15 EDT