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 <dreborier(a)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/hiber...
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 <steve(a)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/hiberna...
> [2]
>
>
https://github.com/sebersole/hibernate-semantic-query/blob/master/hiberna...
> [3]
>
>
https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hiber...
>
_______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>