Hi Emmanual,
I am continuing a history of DDL design tools in java and have jumped into Hibernate Annotations as a possible answer to creating a unified tool set for data base design management (hundreds of designs, thousands of tables).
Here is my take on the general problem you describe.
When class B subclasses class A and class C subclasses B as in your example, I would follow this rule:
1) None of the properties in A are entity columns. (Consistent with serialization and the implicit contract between a subclass and a superclass: the subclass gets nothing but what is declared public and protected and this will generally be methods, behavior). My take is that a superclass not declared as an Entity (written and supported by author X) should not be tricked into becoming an entity because it is subclassed. But, this may be a violation of the spec. Is a superclass implicitly mappable by a subclass in the spec?
2) When an entity class (C in this example) extends another entity class (B), it can should be able to override the column name (annotation overriding) as well as override a method. So Table C would have a column name (c_name) and Table B would have a column name (b_name). This seems completely sensible to be: C.c_name and B.b_name in the db schema.
Anyway, that is the rule I would prefer.
On another matter, I see a lot of examples that kind of look like this:
@Entity public class Person extends Party { @Column(name="person_name") public String getName() {} }
Data modelers are very comfortable using name and not person_name for the column spec. The table name fully qualifies the column as in person.name.
When you use the secondary_table annotation, does hib automagically create the secondary tables during schema generation?
Also, when will there be a second release of the annotation work that fixes some of the restrictions?
Good Work!!!
-Lane
Emmanuel Bernard wrote:
Hi there,
I need to do a choice on annotation overriding in Hibernate Annotation. I do not mean overriding by XML but by annotations.
Here is my based sample public class A { public String getChoice() {} public int getAge() {} }
@Entity public class B extends A { @Column(name="b_name") public String getName() {}
@Transient public int getAge() {} }
@Entity public class C extends B { @Column(name="c_name") public String getName() {} }
Remember that, no annotation on a property means default values.
It seems to me that an annotation should not be overridable in a subclass (this is quite a non sense from a RDBMS perspective), which lead the previous sample to use b_name as a column name. So I will just ignore subclass overriding. Let's call it rule 0.
Now comes the tricky part. Using the XDoclet experience, I currently allow the property of A to be mapped even if A is not an @Entity, so you can"share" the mapping among the different sub entities.
But because of rule 0, you cannot "disable" a mapping (eg A.choice will be mapped), it seems reasonnable that you don't always want the properties of the super class to be mapped.
So what we can do is
1. not mapping the properties of the non @Entity superclasses (age is not mapped because A is ignored)
2. mapping them but not allowing any overriding (except from an XML point of view) (age is mapped becasue B.age is ignored)
3. mapping them and allow subclass overriding up to the root Entity (age is not mapped because B.age override A.age)
This may be quite confusing but I would prefer rule 0 + rule 3 to keep the flexibility. Any opinion?
BTW: the spec does not state this and declare the application using overriding as non portable.
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel