[hibernate-dev] SQM domain type model

[Steve Ebersole]

Ok, I am going to apply SQM-28-2 upstream.

On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole <steve at 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 <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
>>>
>>
>>