What patch are you after? I've already sent you the one with the
changes to MultiQueryImpl.cs; currently, that's the only change that
I've made in the trunk.
As far as whether the parser is ready to be used - other than those
few tests the fail, I think it's in pretty good shape. There are a
couple of code smells in it that I want to clean up, but they are
purely internal and won't change behaviour in any way. The only
"visible" thing that I need to do some work on is the parser error
handling; currently, if you pass in some malformed hql, you don't get
a particularly nice exception.
I think if folk want to start testing it in the real world, that would
be great. I think I'd be very nervous if someone tried to run it in a
production environment :)
Sent from my iPhone
On 15 Apr 2009, at 15:07, Fabio Maulo <[email protected]> wrote:
Steve,
Can you send me a patch with change needed in tests ?
I will review it soon and, where needed, I will write releasenotes
about breaking change.
In your opinion the AST parser is ready to be used ?
2009/4/15 Steve <[email protected]>
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
--
Fabio Maulo
