[hibernate-dev] SQM domain type model

[Steve Ebersole]

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 <steve at hibernate.org> wrote:

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