|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
There are also a couple of other issues with the TYPE(..) expression:
1. Currently TYPE(..) makes use of "case... when" statements to check whether the id for a subtype is NULL (i.e. it is not of this type). This can be fairly expensive as it requires a lot of joins that might not be necessary if the query is restricted to few subtypes and/or fields. Using the discriminator should both be simpler to implement and more efficient.
2. TYPE(..) does not work with relations. If I have entites A and B (each having multiple subtypes) and A holds a single-valued reference to B. Than TYPE(a.b) does not work. The generated SQL query has a "_1" too much and fails to execute. This is, at least, the case with the JOINED table type.
3. TYPE(..) has problem with non-abstract supertypes / entites (e.g. B extends A). If a insert an entity of type A and execute a query with TYPE(..) in the same transaction, then an NPE happens since it is unable to resolve its type.
4. if I have a PER_ENTITY table format, a query with TYPE(...) fails with a H2 database due to an "ambiguous symbol" error in the SQL query.
5. it would be great if one can have an property with the same column name as the the discriminator (+ not updateable/insertable) and that it will be filled with the proper discriminator value.
All this little issues makes it quite hard to work with Inheritance & Hiberate