Kevin,
I haven't taken the time to completely absorb your proposal (it is a Friday
night after all...), but I will offer one bit of advice... The
TABLE_PER_CLASS inheritance type is not widely used nor recommended. And,
I've heard rumors that it might even be deprecated in the JPA 2.0
specification. Granted, even if it's deprecated, it will be supported for
some period of time. Just an observation...
Kevin
On Fri, Oct 10, 2008 at 1:01 PM, Kevin Cox <[EMAIL PROTECTED]> wrote:
>
> Hi all,
> I have a question about inheritance strategies pertaining to abstract
> classes and interfaces. An abstract class and an interface are very similar
> when there are only abstract method declarations; no shared implementation,
> no common properties... The question pertains to both cases where and
> abstract class has common parts or not. The question also pertains when
> you
> have multiple polymorphic classes implementing an interface.
>
> Setting the stage - JPA defines three inheritance strategies:
> @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
> @Inheritance(strategy=InheritanceType.JOINED)
> @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
>
> The interface is covered using @ManagedInterface
>
> However, none of these strategies really do what I think I want to happen.
> So, I need to take the closest one an annotate further.
>
> My desired is to
> 1) Have a table per class to reduce joins and multiple statements for CRUD
> operations (performance opt for a truck load of data). I have a bunch of
> types and don't want a super sparse SINGLE_TABLE.
> 2) Be able to directly resolve an object instance when the class/type and
> id
> are known (1 select statement, nicely indexed), e.g. using em.find(X.class,
> id)
> 3) Be able to resolve a type when only the id is know (not the class) (2
> selects, both indexed) Or, maybe there's a better way?
>
> InheritanceType.TABLE_PER_CLASS gets me the closest, except it does not
> appear to provide a way to for #3 without querying every table representing
> the implementation for the abstract class or interface. You would have to
> query every table until you find the id. Once the id is found, you would
> know the table which corresponds to the class. The problem is that a table
> is not created for the abstract class or interface to allow the reverse
> lookup of the id to the class/type.
>
> Does JPA contain something to deal with the situation? How would one go
> about creating the table for the abstract class or interface?
>
> I think the possible solutions are:
> 1) Use an ID class as the @Id of your abstract class or interface
> (@IdClass)
> even though the id is not compound
> 2) Create a Type class as a property on the abstract class or interface
> 3) Use an id that is a combination of type plus sequence number where the
> type portion can be used to resolve the class. Like circle123456, circle is
> a type of shape. The embedded "circle" make the id a string rather than a
> number, but alleviates the need for a table for the abstract class or
> interface.
>
> Here's the example with an abstract class:
>
> @Entity
> @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
> @DiscriminatorColumn(discriminatorType = DiscriminatorType.STRING)
> public abstract class Item {
>
> @SequenceGenerator(name="ItemSeq", sequenceName="ITEM_SEQ")
> @Id @GeneratedValue(strategy= GenerationType.SEQUENCE,
> generator="ItemSeq")
> private long id;
>
> private String someCommonValue;
> ...
> }
>
> @Entity
> public class ItemA extends Item {
> ... Defines additional properties for type A
> }
> @Entity
> public class ItemB extends Item {
> ... Defines additional properties for type B
> }
>
>
> The same example with interfaces and no common value is:
>
> @Entity
> @ManagedInterface
> public interface Item {
>
> @SequenceGenerator(name="ItemSeq", sequenceName="ITEM_SEQ")
> @Id @GeneratedValue(strategy= GenerationType.SEQUENCE,
> generator="ItemSeq")
> long getId();
> void setId(lond id);
> }
>
> @Entity
> public class ItemA implements Item {
> private long id; //each class holds it's own id based on the sequence in
> the interface definition
> ... Defines additional properties for type A and implement getId, setId
> }
> @Entity
> public class ItemB implements Item {
> private long id; //each class holds it's own id based on the sequence in
> the interface definition
> ... Defines additional properties for type B and implement getId, setId
> }
>
> So, how do you think about this problem? What would you do? Would your
> JPA
> versus non-JPA approaches be different? Any recommended approaches please?
> Thanks,
> Kevin
>
> --
> View this message in context:
> http://n2.nabble.com/How-to-annotation-abstract-class-or-interface-tp1317137p1317137.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
