Hibernate ORM SQL generation
by Steve Ebersole
We've had a few discussions about this in the past. As 5.0 is getting
close to Final (next week), its time to start contemplating our next major
tasks. The consensus pick for that has been the idea of a "unified SQL
generation engine" along with a shared project for the semantic analysis of
HQL/JPQL (and recently it was decided to include JPA Criteria
interpretation here as well).
The central premise is this. Take the roughly 6 or 7 different top-level
ways Hibernate generates SQL and combine that into one "engine" based on
the input of a "semantic tree". The mentioned HQL/JPQL/Criteria shared
project will be one producer of such semantic trees. Others would include
persisters (for insert/update/delete requests) and loaders (for load
requests).
We have a lot of tasks for this overall goal still remaining.
We still have to finalize the design for the HQL/JPQL/Criteria to semantic
tree translator. One option is to proceed with the Antlr 4 based approach
I started a PoC for. John has been helping me some lately with that. The
first task here is to come to a consensus whether Antlr 4 is the way we
want to proceed here. We've been over the pros and cons before in detail.
In summary, there is a lot to love with Antlr 4. Our grammar for HQL
recognition and semantic tree building is very simple and elegant imo. The
drawback is clearly the lack of tree walking, meaning that we are
responsible for writing by hand our walker for the semantic tree. In fact
multiple, since each consumer (orm, ogm, search) would need to write their
own. And if we decide to build another AST while walking the semantic
tree, we'd end up having to hand-write yet another walker for those.
What I mean by that last part is that there are 2 ways we might choose to
deal with the semantic tree. For the purpose of discussion, let's look at
the ORM case. The first approach is to simply generate the SQL as we walk
the semantic tree; this would be a 2 phase interpretation approach (input
-> semantic tree -> SQL). That works in many cases. However it breaks
down in other cases. This is exactly the approach our existing HQL
translator uses. The other approach is to use a 3-phase translation (input
-> semantic-tree -> semantic-SQL-tree(s) -> SQL). This gives a hint to one
of the major problems. One source "semantic" query will often correspond
to multiple SQL queries; that is hard to manage in the 2-phase approach.
And not to mention integrating things like follow-on fetches and other
enhancements we want to gain from this. My vote is definitely for 3 or
more phases of interpretation. The problem is that this is exactly where
Antlr 4 sort of falls down.
So first things first... we need to decide on Antlr 3 versus Antlr 4
(versus some other parser solution).
Next, on the ORM side (every "backend" can decide this individually) we
need to decide on the approach for semantic-tree to SQL translation, which
somewhat depends on the Antlr 3 versus Antlr 4 decision.
We really need to decide these things ASAP and get moving on them as soon
as ORM 5.0 is finished.
Also, this is a massive undertaking with huge gain potentials for not just
ORM. As such we need to understand who will be working on this. Sanne,
Gunnar... I know y'all have a vested interest and a desire to work on it.
John, I know the same is true for you. Andrea? Have you had a chance to
look over the poc and/or get more familiar with Antlr?
11 years
SQM - Shade/shadow Antlr runtime?
by Steve Ebersole
Should we shade/shadow the Antlr runtime in SQM?
The main compelling reason to do so is to isolate our usage, version wise,
from any versions used in environments SQM is deployed into. This is the
typical benefit of shading/shadowing.
The one drawback I can think of is that it stops SQM users from being able
to upgrade the Antlr version used themselves in the runtime. But honestly,
that is not necessarily a bad thing.
11 years
Staging branches on in.relation.to and hibernate.org
by Steve Ebersole
In short, as someone who generally just wants to author some content out
here it is extremely frustrating having to deal with the staging branches
in these 2 repos. Especially when I am trying to do a release. In fact,
authoring content for these 2 related to the release is now my #1
hurdle/roadblock when doing a release.
So when I am working on a release and need to "grab the latest content from
in.relation.to and hibernate.org and start adding my content" what are the
steps I am expected to take? Because every time I get stuck in a maze of
forced update merge conflicts.
11 years
Invalid ORM 5.0.1 Release ZIP on SourceForge
by Gunnar Morling
Hi,
As reported in the forum [1], the ORM 5.0.1 ZIP provided on
SourceForge was corrupted for some reason, it could not be opened.
I've replaced it with the version from BinTray which is valid (it also
is a some megs larger than the original SF version, so I guess
something went wrong during upload?). Re-downloading it, opening it
and verifying it's SHA1 were successful.
The TAR.GZ was fine both on SF and BinTray.
Cheers,
--Gunnar
[1] https://forum.hibernate.org/viewtopic.php?f=1&t=1041473&start=0
11 years
[Hibernate Search] Checkstyle and Eclipse
by Flemming Harms
Hi
What version of the Eclipse checkstyle plug-in should I use? The latest
seems to have trouble using the current configuration due to
RedundantThrows was removed
--
Kind regards / Med Venlig Hilsen
Flemming Harms
-
11 years
Pushed with --force on branch 5.4 of Hibernate Search
by Sanne Grinovero
Hi all,
I did a mistake during a release process and had to amend it by
forcing a push on the 5.4 branch.
I hope it doesn't affect any of you as I only overwrote some trivial
changes from the last couple of hours, but in case I apologise and if
you're in trouble with commits I'm happy to help.
Thanks,
Sanne
11 years
5.0.1 release - tomorrow
by Steve Ebersole
It's too late and I am too tired to start the release tonight. I'll start
it first thing in am.
11 years
