I mean that getting information out of them is not easy. Especially EntityPersister - specifically getting sub/super information, attribute information, etc.
On Thu, Dec 3, 2015 at 10:30 AM andrea boriero <drebor...@gmail.com> wrote: > 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
