11:42 p.m.
On Dec 6, 2012 7:43 AM, "Emmanuel Bernard" <emmanuel(a)hibernate.org>
wrote:
My fear was simply that TypeDescriptor was a class hosted on Hibernate
ORM's codebase. But in retrospect I made that up on my own.
If we have access to the type information via a given class - say
TypeDescriptor - and that TypeDescriptor is hosted on the query parser
project then, we don't have any immediate problem and we can continue to
release OGM when we want while the beefing-up phase of the parser is
done to accommodate ORM's needs.
You are absolutely correct as far as the purpose of TypeDescriptor.
However we do need to realize that a sharing of the parse trees itself
creates a dependency; a dependency on the structure of that tree. If the
structure of the tree changes the consumers of that tree would break. The
structure really needs to be thought of as an api/spi. That's easy(ish)
enough once we get to the point of the unified parser being complete. But
that could be challenging during this "beef up" time.
Of course I understand that the project specific walker (not sure
that's
the correct term), will be able to downcast TypeDescriptor - via the is()
/ as()
pattern - to access the native type (ORM's Type / GridType)
system if
necessary.
The unified parser is only tasked with producing the "intermediate" tree
(aka the semantic representation of the jpql/hql query), not any further
(currently it has the sql rendering walkers too, but those will get moved
to ORM eventually). The important distinction is that project specific
walking of the tree will live in the specific project.
Emmanuel
On Wed 2012-12-05 12:36, Steve Ebersole wrote:
> By "type system" do you mean the TypeDescriptor pull request? If
> not, you'll have to clarify.
>
> If so...
>
> The idea is simple. There are a number of things that the parser
> needs to know in order to figure out the semantics of the query;
> this question of "types" is just one thing. However, ORM and OGM
> have different concrete contracts (Type versus GridType) there.
> TypeDescriptor is simply a "bridge" contract that the parser can use
> in making these semantic decisions. Let's take a few simple
> examples:
>
> 1) ... where p.age + p.birthdate > p.name
>
> Is that a valid restriction?
>
> 2) ... from Person p join p.aliases a
>
> Is that a valid join (not as straight forward as I think you think)?
>
> etc
>
> Answering all those questions depends on access to "type information".
>
> I cannot give you exact details on exactly how the parser determines
> "type information" for each expression yet because we still have
> other unanswered questions that affect the answer to that (most
> notably the question of heterogeneous trees versus homogeneous
> trees).
>
>
> On Wed 05 Dec 2012 10:02:00 AM CST, Sanne Grinovero wrote:
> >That's what I'm hoping too, but since I've not fully grasped the
> >proposed solution for the type system I'm not sure: I need to read the
> >new ORM code.
> >
> >If we really can just plug a different QueryTranslatorFactory in ORM,
> >how does this affect our release options on OGM?
> >
> >
> >On 5 December 2012 15:44, Steve Ebersole <steve(a)hibernate.org> wrote:
> >>I am not completely understanding the question. You don't *need*
Hibernate
> >>5, you could just plug in a custom
QueryTranslatorFactory as we
discussed on
> >>irc. The discussion here was changing the standard
QueryTranslatorFactory
> >>to use this new Antlr parser.
> >>
> >>On Dec 5, 2012 8:46 AM, "Sanne Grinovero"
<sanne(a)hibernate.org> wrote:
> >>>
> >>>Do we need Hibernate 5 to resolve those type system issues?
> >>>
> >>>If so, is there an alternative solution which wouldn't necessarily
> >>>couple the OGM lifecycle with ORM ? (just for the time being)
> >>>
> >>>
> >>>On 4 December 2012 18:19, Emmanuel Bernard
<emmanuel(a)hibernate.org>
wrote:
> >>>>Moving to dev mailing list.
> >>>>
> >>>>On Tue 2012-12-04 12:09, Steve Ebersole wrote:
> >>>>>Can we have such discussions on the dev list?
> >>>>>
> >>>>>Anyway, that's why I said about developing the parser
separately
but in
> >>>>>tandem and synching later. That gives us
that flexibility.
> >>>>>
> >>>>>Because it's not been decided that the parser change will
even go
into
> >>>>>5.0...
> >>>>>On Dec 4, 2012 11:35 AM, "Emmanuel Bernard"
<emmanuel(a)hibernate.org
> >>>>>wrote:
> >>>>>
> >>>>>>Hey guys,
> >>>>>>
> >>>>>>Steve and I started a discussion on how to reuse Sanne's
work
around
> >>>>>>the
> >>>>>>new JP-QL parser. The crux of the problem is to be able to
reuse
the
> >>>>>>type
> >>>>>>of a given node in the parser even if Hibernate ORM and
Hibernate
OGM
> >>>>>>use a
> >>>>>>different type system. This looks doable but then the
problem of
> >>>>>>timing
> >>>>>>arises.
> >>>>>>
> >>>>>>With Davide coming onboard, and even more after BV is behind
us, I
> >>>>>>expect
> >>>>>>OGM to speed up significantly which means we will need to do
fast
> >>>>>>releases.
> >>>>>>So the question is when are we targeting Hibernate ORM 5
final and
> >>>>>>does
> >>>>>>that fit Hibernate OGM's time goals.
> >>>>>>
> >>>>>>We have been promising query for ever now and I would hate
to
have to
> >>>>>>delay it more than necessary.
> >>>>>>
> >>>>>>Thoughts?
> >>>>>>
> >>>>>>Emmanuel
> >>>>>>
> >>>>_______________________________________________
> >>>>hibernate-dev mailing list
> >>>>hibernate-dev(a)lists.jboss.org
> >>>>https://lists.jboss.org/mailman/listinfo/hibernate-dev