Is the idea that some other community project could develop their own alternative "criteria API"?
I think that would be really interesting to encourage - or at least not make it harder - for people to experiment in that direction. But of course, if the cost is high for you maybe that's better addressed at later stage. Thanks Sanne On 6 December 2015 at 20:42, Steve Ebersole <st...@hibernate.org> wrote: > Relatedly I am contemplating simply squashing the 2 modules into 1 module. > The initial idea behind the split was to cater for consumers that wanted to > hook in with Hibernate ORM to pass in a customly built SQM, as opposed to > an SQM built from HQL/JPQL interpretation or criteria translation. > > I'm not sure the use case there is well-defined enough to warrant doing the > split up front, let alone whether that is even a use case we want to > support... > > On Fri, Dec 4, 2015 at 10:28 AM Steve Ebersole <st...@hibernate.org> wrote: > >> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
