Hi there,
I disagree with Lane's first point - that in Emmanuel's example A's
properties would not be mapped in B. This goes against standard Java
serialization. For example, if A were a legacy class and B extended
it to provide EJB annotations, then every accessor would have to be
overridden just to become persistent. Whereas in Java serialization,
B would just extend A and implement Serializable - similar to the
annotation equivalent of B extending A and declaring @Entity on
itself. If properties from A were transient in an EJB context, then B
would simply override those and declare @Transient on them -
continuing the EJB theme of persistent unless declared otherwise.
Aside from that, I agree that annotations should be overridable.
Mark
On Thu, 03 Feb 2005 20:17:02 -0800, Lane Sharman <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------
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
