[hibernate-dev] SQM domain type model

Mon Dec 7 13:21:52 EST 2015

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