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 wrote:
> Ok, I am going to apply SQM-28-2 upstream.
>
> On Thu, Dec 3, 2015 at 10:36 AM Steve Ebersole
> 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
>> 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 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
