Ok, I am going to apply SQM-28-2 upstream. On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <st...@hibernate.org> wrote:
> 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
