[hibernate-dev] SQM domain type model

[andrea boriero]

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 <steve at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>