Hi Oliver,
glassfish_at_javadesktop.org wrote:
> Dear Community,
>
> I'm using Glassfish V2 and Postgres 8.2 on my current project. According to the class model there are versus cases where I need to implement inherited structures and I was almost impressed how easy it was to work with the single table strategy. The most surprising thing was that JPL allowed me to ask for elements of the abstract superclass but returned a collection of a mixture of entities from the leafs of the inheritance structure.
>
> The single table design for me was only useful when there were only few additional properties in the subclasses. So I now came to the mapping of an inherited table structure, but I could not find a good solution with the current toplink implementation to reach similar functionalities as with a single table. So maybe someone from the community could give me some assistance or someone with related problems wants to discuss with me.
>
> The thing is, table inheritance in postgres makes columns in the supertable automatically available in all inherited tables. This leads to select * on the inherited table which will include all columns from the supertable. This is easy to understand and fits exactly what I need from design view. So what is the way now to map the JPA entities for this table design? We have JOINED, TABLE_PER_CLASS or even @MappedSuperclass. The @MappedSuperclass does not seem to be a good candidate because one cannot use MappedSuperclasses in JPL as I'm already sure that I want to ask for all entities of the abstract superclass type in my NamedQueries as I could do with the single table strategy. The JOINED mapping may be a solution (I did not try yet) but there are two points that I'm sceptical about: first table inheritance is not a joined operation (even if it might work, because the ID's of both tables are obviously the same), second I don't really like to include a type column in my superclass as I'm already working with a real type differenciation by different tables. So what I thought would be my friend was the TABLE_PER_CLASS mapping. But when I made my first test I was disappointed that this strategy is not (yet) implemented in the current toplink essential libraries. I'm stuck from here.
>
> My questions are:
> 1) Am I right that TABLE_PER_CLASS would be the right mapping for inherited tables (If it were available)?
>
>
I'd go for the JOINED strategy. With TABLE_PER_CLASS you're duplicating
the common columns in all the tables of the inheritance hierarchy, and
queries on the "root" class join all tables. The JOINED strategy avoids
column duplication, but queries on the "root" class also join all the
tables. Theoretically, you don't need a discriminator column when using
the JOINED strategy. This is only required for the SINGLE_TABLE strategy.
> 2) Can anybody say when TABLE_PER_CLASS will be available?
>
> 3) Did anybody find another solution for inherited table mapping with similar features as the SINGLE_TABLE mapping?
>
Table inheritance in Postgres seems to be an orthogonal feature, which
doesn't match the JPA concept, which assumes that the inheritance is
managed by the Persistence Provider.
> Best regards,
> Oliver
> [Message sent by forum member 'senortorpedo' (senortorpedo)]
>
> http://forums.java.net/jive/thread.jspa?messageID=227902
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>