9:14 a.m.
What do you guys think about this...
fromClause
: FROM^ { weakKeywords(); } fromRange ( onJoin | pathJoin | COMMA! {
weakKeywords(); } fromRange )*
;
onJoin
: ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^
identifier asAlias ON^ logicalExpression
;
pathJoin
: ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^ (FETCH)?
path (asAlias)? (propertyFetch)? (withClause)?
;
The "pathJoin" is basically what we currently support. The "onJoin"
is what we want to support. Does it look correct to you?
11:16 a.m.
On Thursday 20 September 2007 09:14:47 am James Carman wrote:
What do you guys think about this...
fromClause
: FROM^ { weakKeywords(); } fromRange ( onJoin | pathJoin | COMMA! {
weakKeywords(); } fromRange )*
;
onJoin
: ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^
identifier asAlias ON^ logicalExpression
;
pathJoin
: ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^ (FETCH)?
path (asAlias)? (propertyFetch)? (withClause)?
;
The "pathJoin" is basically what we currently support. The "onJoin"
is what we want to support. Does it look correct to you?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
At a bare minimum this would not work because the identifier sub-rule result
(recognized after JOIN) would need to be resolved before allowing the lexer
to continue on to the resolution of the logicalExpression sub-rule.
But even more basic, I don't think "identifier" is the correct sub-rule
here.
It would catch imported entity name scenarios, but obviously fail on
non-imported entity names (aka FQN).
Have you looked the grammars I started for the re-work of the query parser?
It is obviously more work to go this route, but much more correct imo.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/HQL_AN...
11:25 a.m.
Well, how difficult would it be to get the HQL_ANTLR_2 branch
mavenized so that it mimics the layout of the trunk? Wouldn't that
branch, as it currently sits, be very difficult to merge back into the
trunk? Could we make a copy of the trunk to another branch so that we
can copy over your changes into it (I can't do that because I don't
have write permissions)? Then, we can work on that mavenized branch.
On 9/20/07, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thursday 20 September 2007 09:14:47 am James Carman wrote:
> What do you guys think about this...
>
> fromClause
>
> : FROM^ { weakKeywords(); } fromRange ( onJoin | pathJoin | COMMA! {
>
> weakKeywords(); } fromRange )*
> ;
>
> onJoin
>
> : ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^
>
> identifier asAlias ON^ logicalExpression
> ;
>
> pathJoin
>
> : ( ( ( LEFT | RIGHT ) (OUTER)? ) | FULL | INNER )? JOIN^ (FETCH)?
>
> path (asAlias)? (propertyFetch)? (withClause)?
> ;
>
> The "pathJoin" is basically what we currently support. The
"onJoin"
> is what we want to support. Does it look correct to you?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
At a bare minimum this would not work because the identifier sub-rule result
(recognized after JOIN) would need to be resolved before allowing the lexer
to continue on to the resolution of the logicalExpression sub-rule.
But even more basic, I don't think "identifier" is the correct sub-rule
here.
It would catch imported entity name scenarios, but obviously fail on
non-imported entity names (aka FQN).
Have you looked the grammars I started for the re-work of the query parser?
It is obviously more work to go this route, but much more correct imo.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/branches/HQL_AN...
12:07 p.m.
On Thursday 20 September 2007 11:25:00 am James Carman wrote:
Well, how difficult would it be to get the HQL_ANTLR_2 branch
mavenized so that it mimics the layout of the trunk? Wouldn't that
branch, as it currently sits, be very difficult to merge back into the
trunk? Could we make a copy of the trunk to another branch so that we
can copy over your changes into it (I can't do that because I don't
have write permissions)? Then, we can work on that mavenized branch.
Why would it be difficult to merge changes back in?
Work off trunk if you feel more comfortable with that. I'm not pointing out
my branch implying that you work there. I merely point it out to illustrate
imo beneficial changes.
I don't really see the need for a branch quite honestly exactly because you do
not have commit permissions. As long as the final diff is an svn diff (or
you remember the repo revision number you checked out) we'll be fine.
12:20 p.m.
My point is that the directory structure doesn't match that of the
trunk, so it will be very difficult to merge the changes from the
HQL_ANTLR_2 branch back in (I'm no SVN expert, so I may be mistaken
here). So, I guess I can copy your work from the HQL_ANTLR_2 branch
into my local copy of the trunk. That way, when I submit a patch, it
can be easily applied to the trunk.
On 9/20/07, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thursday 20 September 2007 11:25:00 am James Carman wrote:
> Well, how difficult would it be to get the HQL_ANTLR_2 branch
> mavenized so that it mimics the layout of the trunk? Wouldn't that
> branch, as it currently sits, be very difficult to merge back into the
> trunk? Could we make a copy of the trunk to another branch so that we
> can copy over your changes into it (I can't do that because I don't
> have write permissions)? Then, we can work on that mavenized branch.
Why would it be difficult to merge changes back in?
Work off trunk if you feel more comfortable with that. I'm not pointing out
my branch implying that you work there. I merely point it out to illustrate
imo beneficial changes.
I don't really see the need for a branch quite honestly exactly because you do
not have commit permissions. As long as the final diff is an svn diff (or
you remember the repo revision number you checked out) we'll be fine.
12:39 p.m.
Another problem with the code in the branch is that it uses Commons
Logging, whereas the code in the trunk uses SLF4J.
On 9/20/07, James Carman <james(a)carmanconsulting.com> wrote:
My point is that the directory structure doesn't match that of
the
trunk, so it will be very difficult to merge the changes from the
HQL_ANTLR_2 branch back in (I'm no SVN expert, so I may be mistaken
here). So, I guess I can copy your work from the HQL_ANTLR_2 branch
into my local copy of the trunk. That way, when I submit a patch, it
can be easily applied to the trunk.
On 9/20/07, Steve Ebersole <steve(a)hibernate.org> wrote:
> On Thursday 20 September 2007 11:25:00 am James Carman wrote:
> > Well, how difficult would it be to get the HQL_ANTLR_2 branch
> > mavenized so that it mimics the layout of the trunk? Wouldn't that
> > branch, as it currently sits, be very difficult to merge back into the
> > trunk? Could we make a copy of the trunk to another branch so that we
> > can copy over your changes into it (I can't do that because I don't
> > have write permissions)? Then, we can work on that mavenized branch.
>
> Why would it be difficult to merge changes back in?
>
> Work off trunk if you feel more comfortable with that. I'm not pointing out
> my branch implying that you work there. I merely point it out to illustrate
> imo beneficial changes.
>
> I don't really see the need for a branch quite honestly exactly because you do
> not have commit permissions. As long as the final diff is an svn diff (or
> you remember the repo revision number you checked out) we'll be fine.
>
1:44 p.m.
On Thursday 20 September 2007 12:20:10 pm James Carman wrote:
My point is that the directory structure doesn't match that of
the
trunk, so it will be very difficult to merge the changes from the
HQL_ANTLR_2 branch back in (I'm no SVN expert, so I may be mistaken
here). So, I guess I can copy your work from the HQL_ANTLR_2 branch
into my local copy of the trunk. That way, when I submit a patch, it
can be easily applied to the trunk.
That's not going to work either since there are things in that branch I
decided are not a good approach. Especially the PathResolutionStrategy
stuff. It is nice in theory but ended up being way too complex/convoluted.
I still need to give thought to this aspect.
So be selective about what you copy. Unfortunately I do not have time to work
on this; that is the reason I am not :) You'll just need to figure this
stuff out for yourself, with help from this list...
6615
days inactive
6615
days old
6 comments
2 participants
participants (2)
-
James Carman -
Steve Ebersole