The "general roadmap" is the group of issues found at the first JIRA
The second is the main set of changes required. Two things you must
keep in mind before understanding the full breadth of these changes:
1) Hibernate has quite a few places where SQL is generated. This
depends on perspective a bit. What I mean is that there is (mostly) a
single place where SQL *fragments* are generated (the persisters) but
many places where these fragments are assembled and many places where
Dialect rules are applied.
2) Currently HQL queries are translated in 3 phases (3 distinct Antlr
grammars). The first largely just tokenizes the query and builds what
Antlr terms an Abstract Syntax Tree (AST). The third phase simply walks
an AST and produces a SQL string from it. The second phase does
What we had decided was that the second phase should be split up into 2
separate, well-defined phases (well-defined in terms of both their
purpose and the structure of their resulting AST). Then HQL translation
will have 4 phases, the first 2 of which will be specific to HQL; the
last two will be generically applicable to ASTs representing queries in
terms of persisters and properties (what JAP calls the abstract schema).
The purpose of the *new second phase* is to normalize the HQL AST. What
that means is to remove unnecessary redundancy. As a trivial example,
there are 2 broad ways to represent a join in HQL (1) explicitly via the
JOIN keyword; or (2) implicitly via property dereferencing. The former
is a much more simple structure with which to do deal, so normalization
of implicit joins will convert them to their corresponding explicit
I need to have this done for 3.4.
Principal Software Engineer
JBoss, a division of Red Hat
On Mon, 2008-12-29 at 13:34 -0500, David Mansfield wrote:
Thanks for the reply.
Is there a general roadmap to these changes somewhere so I can get a
gist of what's going on there? Also a general timeframe for this stuff
to reach a stable release? I'm definitely interested to take a
On Mon, 2008-12-29 at 09:44 -0600, Steve Ebersole wrote:
> I am in the midst of significant changes which will affect the way
> criteria queries are interpreted/translated. This is all happening on a
> branch named SQL_GEN_REDESIGN. If you are interested in helping that
> effort along or making sure this particular issue is addressed by those
> changes then we can chat about that. For the former, perhaps we could
> chat on IRC (#hibernate-dev on freenode), though email is ok too. For
> that latter, though, we'd have to wait for this work to be done; you can
> track it from JIRA :
> Steve Ebersole
> Project Lead
> Principal Software Engineer
> JBoss, a division of Red Hat
> On Mon, 2008-12-22 at 15:49 -0500, David Mansfield wrote:
> > [ I sent this about a week ago and haven't heard anything from anyone.
> > Can someone let me know if I'm barking up the right tree? ]
> > Hi All,
> > The attached patch, which is not quite ready for inclusion, but works
> > completely under light testing, implements the functionality
> > missing from the criteria API for querying collections that are not
> > collection-of-entity. (ie. fix the causes of 'collection is not an
> > association', (i.e first issue on 'Advanced Problems' faq)).
> > This needs some feedback and review. I have created issue
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3646
> > track the issue, but I've not yet received any feedback.
> > Implementation notes:
> > The main area of change is to the CriteriaQueryTranslator class. In
> > this class, we replace the 'criteriaEntityNames' map of Criteria =>
> > String with two maps, one mapping Criteria => CriteriaInfoProvider and
> > one mapping String (name) => CriteriaInfoProvider.
> > The new class, CriteriaInfoProvider is an interface/abstraction to the
> > functionality needed by the various entry points into the translator,
> > such as to retrieve the 'spaces', get the PropertyMapping etc.
> > There are 3 concrete implementations of CriteriaInfoProvider:
> > * EntityCriteriaInfoProvider: this is the functionality that was always
> > present in the translator, ie. use getEntityPersister() etc.
> > * ComponentCollectionInfoProvider: this is the functionality that
> > extends the api for collection-of-component. In this class, we have to
> > provide the collection 'spaces' and the 'collection persister',
> > also have to look in detail at the ComponentType to be able to resolve
> > property references off of the component.
> > * ScalarCollectionInfoProvider: this is the functionality the provides
> > the api for collection-of-value. The main thing here is we use the
> > SessionFactoryHelper (part of the HQL tree) to get the
> > CollectionPropertyMapping object for mapping the
> > etc. properties. There's at least one 'I have no idea what to put
> > method in this class.
> > There is substantial cruft in the patch for debugging, which will not be
> > part of the final implementation.
> > There is a crude hack in CriteriaJoinWalker which needs some expert
> > advice: the existing implementation was looking at some mysterious
> > 'consumesEntityAlias' boolean, but I need to force the code to lookup
> > the alias from the translator every time, or else it bypasses the alias
> > for the collection itself, and the SQL aliases are wrong.
> > There is also a completely separate bugfix wedged in here, which needs
> > to be extracted to its own issue/patch. The changes to JoinWalker are
> > necessary and correct: if the last association will not generate any
> > selectFragment, then the implementation adds an extraneous ", " to
> > generated string.
> > Looking forward to your feedback and working together to get this into
> > the tree. Need info about test cases to create, documentation etc.
> > Thanks,
> > David Mansfield
> > Cobite, INC.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev