Community
Participate
Working Groups
Build ID: wtp 3.0.1 07/28 Steps To Reproduce: Given an inheritance hierarchy like this involving two beans: @Entity @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) public abstract class Notice implements Serializable @Entity public class OverdueNotice extends Notice When connected to a database schema which only has tables/columns matching the "OverdueNotice" bean, the JPA validator complains about not resolving tables/columns for the abstract super class "Notice" The spec says for the TABLE_PER_CLASS strategy, tables are only expected for concrete beans so I think the validator shouldn't even attempt to resolve tables/columns for abstract entity beans? Ref: http://java.sun.com/javaee/5/docs/api/javax/persistence/InheritanceType.html#TABLE_PER_CLASS More information:
We don't correctly handle the TABLE_PER_CLASS strategy as noted. Given that this results in invalid error message I am going to target this at 2.0.2 for now. Depending on the complexity/risk of the fix, this may have to move to a future release.
I am retargeting this to the 2.1 release. I think the changes are going to involve some api changes. This bug needs more investigation and really needs to be a complete effort to support 'table per class' inheritance. Currently this is not a requirement of the JPA spec and might not even be a requirement of the 2.0 spec, not sure if they have made that decision yet. We need to look at how this affects tables, columns, secondary tables, join tables, etc on abstract entities. Also need to handle attribute overrides in this case? Currently you can only set attribute overrides if your superclass is a MappedSuperclass, not an abstract entity class. I am not sure if this is an appropriate use case for attribute overrides.
I've a question ... from my naive reading ... and seems comment #1 and #2 are say slightly different things. Is there two problems here? That we don't handle the case and also that there is an invalid error message? I'm wondering if there is a compromise to soften the error message (maybe make a warning?) and then later actually handle the case? Or ... am I misunderstanding? Thanks,
(In reply to comment #3) My comment #1 was probably a little lacking. The problem here is unfortunately more systematic than a particular errant error message. The errors in question here are not inheritance specific, but are really the core errors in Dali, when database metadata does not resolve with entity defaults. So, in this case we can't easily make them go way, or downgrade them without affecting the standard use cases. As Karen mentions, solving this problem properly is fairly involved. This table_per_class strategy is an uncommon one, and not actually required to be supported by a JPA implementation in JPA 1.0, so it has received less attention to date as the more common inheritance use cases. With all of that said, our plan would be to fix this by including the model support necessary for this inheritance strategy in a release, either 2.1 or 2.2, as time is already tight for 2.1. Let me know if a fix is needed in maintenance and we can take a another look to see if there is a reasonable way to safely prevent these problems from appearing.
Retargeting to 2.2 release. This is a larger work effort that involves new functionality. Trying to limit the number of issues that remain for 2.1 now that M3 is closing down.
fixed in M6, completed the table-per-class inheritance support. DB Validation no longer occurs on an abstract table-per-class entity. Defaults for table/schema/catalog on entities are calculated based on the inheritance strategy
