AIL PROTECTED]>
To: "Joshua Davis" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 18, 2003 6:13 AM
Subject: Re: [Hibernate] Re: AST parser for HQL
> On Mon, Nov 17, 2003 at 11:54:54AM -0800, Joshua Davis wrote:
> > That's a neat idea. So
ct: Re: [Hibernate] Re: AST parser for HQL
> > How about we get a list of ANSI-standard SQL functions and portably
> > support those and those only (I don't think there are many of them).
>
> This makes a lot of sense. However, what if something so commonly used
(like a
>
It does not pose much of a problem for the grammar,
especially if the tokens are such that this can be
done with the lexer. Then it is simply a matter of
plugging in the pass through token into the grammar
where it is appropriate (e.g. as an expression
'atom').
Don't know what it means for the ba
--- Chris Nokleberg <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 17, 2003 at 11:54:54AM -0800, Joshua
> Davis wrote:
> I suppose you could do something like
> raw "current date"
>
> So 'raw' becomes a keyword that modifies the next
> token.
Yes. Users of an old system that I worked on that
transla
--- "Les A. Hazlewood" <[EMAIL PROTECTED]> wrote:
> > have a prefix that indicates it should flow
> through into the resulting
> > xml
>
> I think you meant resulting sql, right? ;)
>
Errr... yeah. Did somebody say XML?
__
Do you Yahoo!?
Protect your identity wi
> have a prefix that indicates it should flow through into the resulting
> xml
I think you meant resulting sql, right? ;)
Les
---
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer fr
On Mon, Nov 17, 2003 at 11:54:54AM -0800, Joshua Davis wrote:
> That's a neat idea. So, 'raw:' would be a
> pass-through that would pass things directly to the
> underlying engine. The only issue there is when the
> underlying syntax does not obey the rules of the
> over-arching grammar (e.g. 'cu
> I would rather you go the other way, i.e. unprefixed functions should be
> portable ANSI-derived aliases which are mapped by the dialects to the
> necessary names. For driver-specific functions you could potentially
> have a prefix that indicates it should flow through into the resulting
> xml, e
The preprocessor approach might be redundant if I can
get the grammar to recognize the old syntax. Of
course, that's a medium sized 'if' there.
--- Gavin King <[EMAIL PROTECTED]> wrote:
> I think this is our plan. Any insurmountable
> problems with that, do you
> think?
>
> (Devils in the detai
LOL! Ya know what? I had implemented this *exact
same* tranform back when I was writing a 4GL compiler
at work.
This one's easy though:
ident '('[METHOD_CALL] expr => expr '.' ident
'('[METHOD_CALL]
Especially since parens are not use for array
subscripts, like they were in the 4GL. :-P
I'll
On Mon, Nov 17, 2003 at 01:05:50PM -0500, Les A. Hazlewood wrote:
> > How about we get a list of ANSI-standard SQL functions and portably
> > support those and those only (I don't think there are many of them).
>
> This makes a lot of sense. However, what if something so commonly used (like a
> c
> How about we get a list of ANSI-standard SQL functions and portably
> support those and those only (I don't think there are many of them).
This makes a lot of sense. However, what if something so commonly used (like a
current_timestamp() function) is not part of the ANSI standard (assuming ANSI
I think this is our plan. Any insurmountable problems with that, do you
think?
(Devils in the details, obviously.)
We might almost be able to replace the hql package with a
preprocessor/postprocessor that predigests the query into a form that
the new parser can swallow. I don't think this is i
How about we get a list of ANSI-standard SQL functions and portably
support those and those only (I don't think there are many of them).
David Channon wrote:
I think limited application of aliases would be beneficial but query
substitutions would work in many situations. The current date issue I
breaking to much existing code. Don't want to do this lightly. Is this step
with the new parser and possible changes to the supported syntax a Version 3
option?
I think so.
No. we need this now. The longer we stay with the existing parser, the
harder it becomes to ditch it in the long run.
We
On 18 Nov (00:47), David Channon wrote:
> Postgress= now()
Thats good.
> breaking to much existing code. Don't want to do this lightly. Is this step
> with the new parser and possible changes to the supported syntax a Version 3
> option?
I think so.
--
Christian Bauer
[EMAIL PROTECTED]
AIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 18, 2003 12:01 AM
Subject: Re: [Hibernate] Re: AST parser for HQL
> I don't think we are realistically going to be able to dream up portable
> aliases for everything. I can see an argument for doing it for a c
Another thought.
Would it be nice to be able to express:
upper(customer.name)
as the more object-oriented:
customer.name.upper()
How hard would this be to implement in the parser? Especially, how hard
would it be to make the parser spit out the exact same AST in either case?
--
Gavin K
to
solve the problem?
Josh
> -Original Message-
> From: Gavin King [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 9:02 AM
> To: Joshua Davis
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Hibernate] Re: AST parser for HQL
>
>
> I don't think we are r
a Davis; hibernate list
> Subject: Re: [Hibernate] Re: AST parser for HQL
>
>
>
> >>Finally, why is the "having" node a submode of the "group" node?
> >
> >
> > Because it is a dependent sub-clause of 'group by' at the
&
I don't think we are realistically going to be able to dream up portable
aliases for everything. I can see an argument for doing it for a couple
of very important cases like current date. Beyond that I wouldn't really
like to go there. Note that you can't have both really ... as soon as
you hav
vember 17, 2003 1:25 AM
> To: Les A. Hazlewood; [EMAIL PROTECTED]
> Subject: Re: [Hibernate] Re: AST parser for HQL
>
>
>
> In the select clause there is the option to include the
> current date native function as a part of the dialect. As
> Joshua stated the parser looks t
[IDENT]
|| \-'as' [ALIAS]
|| \-'d' [IDENT]
|\-'where' [LITERAL_where]
| \-'=' [EQ]
| +-'.' [DOT]
| | +-'d' [IDENT]
| | \-'gob' [IDENT]
|
Finally, why is the "having" node a submode of the "group" node?
Because it is a dependent sub-clause of 'group by' at the moment. Is that
not the case?
H. I suppose it is. well, as long as we can support
from . where group having .
as well as the traditional
from .
Responses below
> -Original Message-
> From: Gavin King [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 6:50 AM
> > -- Grammar problem #1: The 'from Order order where' examples --
> >
> > Also, notice that I changed 'order' to 'ord' in many of the HQL
> > examples in the
On 18 Nov (00:05), Gavin King wrote:
> Does the parser handle:
>
> * subselects (can't notice one anywhere)
> * floating point and decimal literals
> (it doesn't need to parse them, just recognize them)
I'd also plan for "select new Foo(count(bar))".
> This is the "implicit group by" we discu
Does the parser handle:
* subselects (can't notice one anywhere)
* floating point and decimal literals
(it doesn't need to parse them, just recognize them)
We also want to plan for the following new syntax:
select foo, count(bar)
from Foo foo outer join foo.bars bar
group
This is the "imp
-- Grammar problem #1: The 'from Order order where' examples --
Also, notice that I changed 'order' to 'ord' in many of the HQL examples in
the hibernate documentation. This is because 'order' is a keyword, and the
statement:
Don't worry. Just outlaw keywords as identifiers. The reality is that
-
From: "Les A. Hazlewood" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 17, 2003 8:08 AM
Subject: RE: [Hibernate] Re: AST parser for HQL
> > I am not familiar with the 'current date' construct in this example:
> > "from Calendar
Yeah - just want to say that I'm looking very much forward to
see this integrated into Hibernate...it would make it much easier for
mortals to enhance/extend Hibernate with respect to HQL.
Maybe we could even get a taste of the parser now ? Any src available for it ?
/max
David Channon wrote:
Gr
> I am not familiar with the 'current date' construct in this example:
> "from Calendar cal where cal.holidays.maxElement > current date"
>
> Is 'current' a function? If so, is 'date' the argument? Is this ORACLE
> specific?
"current date" would need to be a Hibernate defined token.
Oracl
rrent date' problem --
I am not familiar with the 'current date' construct in this example:
"from Calendar cal where cal.holidays.maxElement > current date"
Is 'current' a function? If so, is 'date' the argument? Is this ORACLE
specific?
Great work. This will make further enhancements to the Select clause much
easier.
Here are a few more queries from the test package that I use to test some of
the more
recent (and not so well documented) changes to the select clause, eg,
dialect functions.
This one is not recent but affects the pa
33 matches
Mail list logo
