The more I think about it the more I think it makes the most sense to do
this in 2 steps/phases. So we'll have one step that takes the SQM and
generates a "SQL tree"; and then an additional step that renders the "SQL
tree" into the SQL string (and friends).
On Sat, Sep 5, 2015 at 1:04 PM Steve E
Getting back to this work this weekend and next week.
Initially I am working on the basics for SQL generation from a SQM model.
There was an open question before with regards to whether it made sense to
render the SQM directly into SQL (String) or whether it instead made sense
to render the SQM in
On 27 August 2015 at 18:30, Steve Ebersole wrote:
> Nevermind. I will not do that. I think I have found a still-easyish way
> to do it.
Great! Highly appreciate that.
>
> On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole wrote:
>
>> I do want to pull ORM in to the hibernate-sqm module as a tes
Nevermind. I will not do that. I think I have found a still-easyish way
to do it.
On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole wrote:
> I do want to pull ORM in to the hibernate-sqm module as a test dependency
> to be able to more easily set up the ModelMetadata stuff based on a
> SessionF
I do want to pull ORM in to the hibernate-sqm module as a test dependency
to be able to more easily set up the ModelMetadata stuff based on a
SessionFactory. That is possibly awkward later when we then use
hibernate-sqm in ORM in terms of having 2 different versions of ORM. I am
open to alternati
2015-08-26 14:41 GMT+02:00 Steve Ebersole :
> On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling wrote:
>>
>> Hi Steve,
>>
>> > 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. O
On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling wrote:
> Hi Steve,
>
> > 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
Hi all,
joining the party late, just read it all up.
I'm highly +1 to multiple phases, I think it's a requirement for e.g.
cached reuse.
About ANTLR4 : it sounds better than ANTLR3 for maintenance reasons;
but I don't think we can grasp the full picture of all the things we
want to do and say "it
Hi Steve,
> 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.
I agree in the case where "the query includes more than one". However,
there are definitely valid uses for these.
Consider this case e.g...
interface Auditable {
String createdBy;
Instant createdAt;
String updatedBy;
Instant updatedAt;
}
@Entity
class Account implements Auditabl
In practice, when are unmapped inheritance queries typically used? I
tend to see them only for bulk deletions, IIRC. But in general, I'd
assume they're a product of "doing something incorrectly", especially if
the query includes more than one. On 08/24/2015 08:40 AM, andrea boriero
wrote:
>
Another thing I think we ought to consider longer term is to replace the
contracts in the org.hibernate.sqm.domain package with
the javax.persistence.metamodel JPA model.
However, for ORM we cannot do that yet due to a major prerequisite.
Basically that would require the "melding" of hibernate-cor
On Mon, Aug 24, 2015 at 8:00 AM John O'Hara wrote:
> The split makes a lot of sense, should we have another module for the
> criteria query SQM translation?
>
I personally think that makes no sense to do.
As we only have one grammar for HQL and JPQL, does jpql come under the
> hibernate-hql-pa
The split makes a lot of sense, should we have another module for the
criteria query SQM translation?
As we only have one grammar for HQL and JPQL, does jpql come under the
hibernate-hql-parser-antlr4poc module?
On 21/08/15 21:51, Steve Ebersole wrote:
> Just a heads up that I started a major
I have nothing against your proposal so +1
On 24 August 2015 at 04:55, Steve Ebersole wrote:
> Another point I want to discuss up from because it affects tree
> structure. Specifically the idea of an "unbounded implicit inheritance"
> query. These are queries like "from java.lang.Object". Qu
Another point I want to discuss up from because it affects tree structure.
Specifically the idea of an "unbounded implicit inheritance" query. These
are queries like "from java.lang.Object". Queries where the from clause
pulls in "unmapped inheritance". These are fine, to an extent. Hibernate
h
I got that initial refactoring pushed to my fork...
On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole wrote:
> Just a heads up that I started a major refactoring of the antlr4 poc
> project in preparation for starting to look at this next sql-gen step.
>
> First I am making it into a multi-module p
Just a heads up that I started a major refactoring of the antlr4 poc
project in preparation for starting to look at this next sql-gen step.
First I am making it into a multi-module project. We will have the
hql-parser module, but then also an orm-sql-gen module to be able to play
with that part.
I haven't seen it, I'm going to read it.
On 21 August 2015 at 16:54, Steve Ebersole wrote:
> http://www.antlr2.org/article/1170602723163/treewalkers.html
>
> Not sure if y'all have seen this. Its an old article advocating manual
> tree walking (what we are facing here) over using generated tree
http://www.antlr2.org/article/1170602723163/treewalkers.html
Not sure if y'all have seen this. Its an old article advocating manual
tree walking (what we are facing here) over using generated tree walkers.
On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole wrote:
> I agree. Its my biggest hang
I agree. Its my biggest hang up with regard to using Antlr 4. Actually,
its my only hang up with Antlr 4, but its a huge one.
On Tue, Aug 18, 2015 at 9:30 AM andrea boriero wrote:
> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look at
> your poc.
>
> Apart some problems to
yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a look at
your poc.
Apart some problems to fully understand the semantic model (due to my lack
of a complete knowledge of the domain problem),
I agree with you about the simplicity and elegance of the grammar for
HQL recognition
and
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/J
23 matches
Mail list logo
