No reason that I can think of why that wouldn't work - use the classic parser for your regular HQL queries, and the AST parser for LINQ (under the covers, the LINQ code is going just create the AST parser directly so the configuration is not important).

I think the only time you'd *have* to switch to the AST parser for regular HQL stuff is if you wanted bulk update functionality (or any other new function that we only add into the AST parser).

On 15 Apr 2009, at 12:01, Ayende Rahien wrote:

Steve,
Do we even need to make activate the new parser in order to use it?
I would assume that we can use the classic parser and still take advantage of AST to query support, no?

On Wed, Apr 15, 2009 at 11:07 AM, Steve <[email protected]> wrote:

My call is that it shouldn't work.  In .Net, you can't compare two
types that are different.  Just because the Id's happen to match
doesn't imply equality in any way, IMO.  Being forced to add the .Id
(as in e.Reverse.id = a.Forward.id) makes the developer's intentions
clear.

Note that if the types match, then the .Id isn't necessary.  So
"e.Reverse = e.Reverse" is absolutely fine (poor example, since it's a
tautology, but I'm sure you get the point!).

Whether we're happy to take a breaking change is another issue.  My
feeling is that the new parser should *not* be the default, that way
any breaking changes (either intentional or accidental through unknown
bugs) won't impact the community.  If anyone wants LINQ support, or
bulk updates, or any other feature that requires the new parser, then
they should be explicit in their configuration and make sure that they
run a full regression test of their system.  That way, we don't have
to be quite so concerned about making the two parsers match
exactly.  I think that there are good advantages to staying roughly in
sync with Hb, and these breaking changes are ones that they seem to
have been happy to take.

On Apr 15, 8:53 am, Ayende Rahien <[email protected]> wrote:
> So, should it work or shouldn't it work?
>
>
>
> On Wed, Apr 15, 2009 at 9:33 AM, Fabio Maulo <[email protected]> wrote:
> > 2009/4/15 Ayende Rahien <[email protected]>
>
> >> I would say that this should be broken then.
> >> What I would expect it to do is compare the ids, but that is okay, since
> >> we can just user e.Reverse.id = a.Forward.id
>
> > but the default, in case of relations, is the id
>
> > --
> > Fabio Maulo


Reply via email to