Blazebit
Polymorphic queries currently not supported
public interface Permission { }
@Entity
public class UserPermission implements Permission { }
@Entity
public class UserGroupPermission implements Permission { }
"SELECT p FROM Permission p"
Hibernate generates two separate SQL queries for the above JPQL query. We currently do not handle this case in any way. Problems might arise wherever we deal with SQL directly:
- Set Operations (UNION etc)
- CTEs
- Returning Support
- Special cases of limit
Maybe we could also support polymorphic subqueries.
Tasks
- [ ] Implement query per subtype strategy
- [ ] Implement UNION strategy
- [ ] Documentation
Just querying them like you showed might not be a big problem, but how do you expect to be able to filter properties? Implicit downcasting was removed in 1.2.0-Alpha2 and I am not really planning to revive it.
If you want to allow doing further operations like filtering, grouping etc. on a permission we have the following options
- Construct a metamodel for the interfaces which contains all the commonalities of the subtypes implementing it. Then we can use that metamodel for building the query
- Introduce implicit downcasting just for JoinNodes involving interface types
Apart from that, we have to decide how we implement this behind the scenes. Queries that don't select relations with polymorphic types could actually be implemented by using a UNION operator, because in that case, the generated SQL select clauses for the subtypes will have matching types. When polymorphic types are involved the column count and types can vary, so for such queries we'd have to execute a query for every subtype.
Do we want to allow an interface just as query root or also as cross/entity join like "SELECT ... FROM Permission p, Permission p2"? I think the strategy which executes queries per subtype will break with such queries, so I'd say we either disallow cross/entity joins as a whole or only support the case when the query can be formulated as UNION query.
How about supporting the interface type in nested queries like subqueries, CTEs or as SET operand? This obviously can only work when we can transform the query into a UNION query.
If that simple query is all you want to do, I'd rather not support this feature at all. I'd like to hear more about the use case and how you would expect blaze-persistence to behave or to support that use case.
@beikov has there been any movement on this functionality? Looks like it hasn't been touched in a long time.
Hi @jcputney, would you mind sharing your use case? I'm kind of unsure what this would be useful for in Blaze-Persistence since people can just use plain HQL for these simple things.