[hibernate-dev] SQM domain type model

[Sanne Grinovero]

Is the idea that some other community project could develop their own
alternative "criteria API"?

I think that would be really interesting to encourage - or at least
not make it harder - for people to experiment in that direction.
But of course, if the cost is high for you maybe that's better
addressed at later stage.

Thanks
Sanne

On 6 December 2015 at 20:42, Steve Ebersole <steve at hibernate.org> wrote:
> 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
>>>>>
>>>>
>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev