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
PGP.sig
Description: This is a digitally signed message part
