[hibernate-dev] SQM domain type model

[Steve Ebersole]

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 at 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 <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
>>
>
>