SQM needs information about the domain model being queried. In the initial original Antlr redesign work I did, I opted for a completely new "type system" specific to the parsing. The main reason for this was to allow for "other consumers" (besides Hibernate ORM) of its services. By and large we have all agreed that should no longer be a design requirement. But that still leaves us with the question of what we should do in SQM moving forward. We have a few options on how to achieve this. At the highest level we could either reuse an existing type system or we could develop a "SQM specific" type system.
Reusing an existing type system really boils down to 2 options: 1) Use the Hibernate ORM type system (Type, EntityPersister, CollectionPersister) 2) Use the JPA type system (javax.persistence.metamodel.Type, etc) I have a prototype[1] of SQM using the JPA type system. There are some major limitations to this approach, as well as some very significant benefits. The main benefit is that it makes it much more trivial to interpret JPA criteria queries (no conversion between type systems). However, as I said the limitations are pretty significant. Put simply, the JPA type system is very inflexible and certain concepts in Hibernate simply would not fit such; this includes ANY type mappings, dynamic (EntityType.MAP, etc) model types, BAG and IDBAG collections, etc. Also, it defines a lot of things we don't need nor care about for query translation. All in all, I'd vote against this. Using the HIbernate type system is a viable alternative. Though I think that works best if we move SQM in its entirety upstream into the ORM project (otherwise we have a bi-directional set of dependencies). The only drawback is that the Hibernate ORM type system is not very consumption friendly ;) The flip side is to develop a SQM-specific type system. We have 2 prototypes of that at the moment. First[2] is the original one I pretty much copied directly over from the original Antlr redesign work I mentioned above. I'd against vote against this one; I started looking at alternatives for a (few) reason(s) ;) The second[3] is one I developed loosely based on the JPA type system, but more flexible, more aligned with Hibernate concepts and limited to just query translation-related concerns. I am open to alternatives too. Thoughts? [1] https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ExtendedMetamodel.java [2] https://github.com/sebersole/hibernate-semantic-query/blob/master/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/ModelMetadata.java [3] https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
