Not so much an alternative criteria API, more an alternative representation
of (what will become) the internal Hibernate understanding semantically of
a query. I do see the benefit in that, which is why I proposed it and
designed this all with that ultimately in mind :). Honestly, I am at the
point of "let's just get this developed"
FWIW I want to squash these modules (and already did it) because there is a
case where having the SQM model accept some parsing contracts makes the
design much cleaner. And really squashing these modules into one to
achieve that does not forgo allowing someone to pass a custom built SQM to
Hibernate.
On Mon, Dec 7, 2015 at 8:35 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
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(a)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(a)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(a)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(a)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/hiber...
>>>>
>>>> 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(a)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/hiberna...
>>>>> [2]
>>>>>
>>>>>
https://github.com/sebersole/hibernate-semantic-query/blob/master/hiberna...
>>>>> [3]
>>>>>
>>>>>
https://github.com/sebersole/hibernate-semantic-query/blob/SQM-28-2/hiber...
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev