after reading your mail, I'm more inclined towards the solution you started implementing in SQM-28-2. https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hibernate-sqm/src/main/java/org/hibernate/sqm/domain/DomainMetamodel.java
Just a clarification, what do you mean when you say "the Hibernate ORM type system is not very consumption friendly" Thanks On 3 December 2015 at 15:38, Steve Ebersole <st...@hibernate.org> wrote: > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
