DBMS tables do not override in general.
Consider logically joined tables
Party <-- Person where Person is a table which qualifies a party
Party <-- Company where Company is a table which qualifies a
party
Person <-- DeadPerson is a table which qualifies a person.
Party.name cou
Java handles subclasses with identically named fields differently than
some other OO languages I've used, allowing the subclass to have it's
own property. From that perspective, it would be consistent to have c
have it's own name property, but just because Java does it that way
doesn't mean t
> Aside from that, I agree that annotations should be
> overridable.
Hum, up to now I *really* dislike this idea. It seems
to be very unintuitive to me.
In SINGLE_TABLE and JOINED_TABLE strategies, it seems
very weird to override annotations.
Imagine b.getName() should be persisted in the b_name
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 ju
