Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:EclipseLink/Development/JPA 1.0/table per class"
(→Isn't this just Interface descriptors?) |
(→Isn't this just Interface descriptors?) |
||
| Line 3: | Line 3: | ||
* This seems to be just interface descriptors, the requirements seem to be identical, it matters little whether the classes have an interface or abstract class in common. Is would seem odd to have two pieces of identical duplicate code. Perhaps subclass TablePerClassInheritancePolicy from InterfacePolicy not InheritancePolicy. | * This seems to be just interface descriptors, the requirements seem to be identical, it matters little whether the classes have an interface or abstract class in common. Is would seem odd to have two pieces of identical duplicate code. Perhaps subclass TablePerClassInheritancePolicy from InterfacePolicy not InheritancePolicy. | ||
** [Guy] Not sure I understand. The support is for a table per concrete class where the root is also an entity. In my testing, all the classes are concrete entities, none are abstract classes. | ** [Guy] Not sure I understand. The support is for a table per concrete class where the root is also an entity. In my testing, all the classes are concrete entities, none are abstract classes. | ||
| + | *** [[User:James.sutherland.oracle.com|James.sutherland.oracle.com]] : The root class could be abstract or concrete I suppose, it is still identical to interface support, just with an additional implementor. The InterfacePolicy already has the functionality to re-execute queries and union the results together in memory, seems odd to be duplicating this. | ||
* Why not just use the existing interface support, just add an interface descriptor for the abstract class (and process it as a MappedSuperclass)? | * Why not just use the existing interface support, just add an interface descriptor for the abstract class (and process it as a MappedSuperclass)? | ||
* We currently only support VariableOneToOne with interfaces, 1-1, 1-m, m-m are in theory possible just by setting the reference class, but most likely will not work as it is probably a lot more complex than just querying (deletes, mapping fields, pk uniqueness, type fields, constraints, ddl). | * We currently only support VariableOneToOne with interfaces, 1-1, 1-m, m-m are in theory possible just by setting the reference class, but most likely will not work as it is probably a lot more complex than just querying (deletes, mapping fields, pk uniqueness, type fields, constraints, ddl). | ||
Latest revision as of 12:23, 9 December 2008
Isn't this just Interface descriptors?
- James.sutherland.oracle.com 18:51, 8 December 2008 (UTC)
- This seems to be just interface descriptors, the requirements seem to be identical, it matters little whether the classes have an interface or abstract class in common. Is would seem odd to have two pieces of identical duplicate code. Perhaps subclass TablePerClassInheritancePolicy from InterfacePolicy not InheritancePolicy.
- [Guy] Not sure I understand. The support is for a table per concrete class where the root is also an entity. In my testing, all the classes are concrete entities, none are abstract classes.
- James.sutherland.oracle.com : The root class could be abstract or concrete I suppose, it is still identical to interface support, just with an additional implementor. The InterfacePolicy already has the functionality to re-execute queries and union the results together in memory, seems odd to be duplicating this.
- [Guy] Not sure I understand. The support is for a table per concrete class where the root is also an entity. In my testing, all the classes are concrete entities, none are abstract classes.
- Why not just use the existing interface support, just add an interface descriptor for the abstract class (and process it as a MappedSuperclass)?
- We currently only support VariableOneToOne with interfaces, 1-1, 1-m, m-m are in theory possible just by setting the reference class, but most likely will not work as it is probably a lot more complex than just querying (deletes, mapping fields, pk uniqueness, type fields, constraints, ddl).
- What will occur for Update-All, Delete-All queries?
- [Guy] - They currently will only execute against the one table. The chaining of updates across all the tables in the hierarchy currently does not work.
- Will joins be supported? Join fetch? Batch reading?
- [Guy] - I'll have to test these further, not sure how much if any of it we get for free. If nothing, then no they will not be supported.
- Will we use an SQL UNION?
- [Guy] No, multiple SELECT statements occur. (see comment below)
- Not sure I understand the bit on preparing and cloning selectionQueries?
- [Guy] Cloning the selection queries is used to create the multiple selects to all the sub-class tables when populating mappings. It also seemed a better to way to ensure we don't lose or overwrite things like you mentioned above (mapping fields, pk uniqueness etc). I found just cloning the read all query and updating the descriptor/reference class was not enough. Most often an invalid field node would occur.
- This will need a lot of testing, crud, merge, queries.
- [Guy] Currently have a number of tests that verify the 1-1, M-1, 1-M and M-M mappings. Along with some named queries and other things like optimistic locking.