I'm pretty sure that that tests fails in Java with their ast parser; I
don't have my machine so can't check at the moment.
Note that (if I remember correctly) the whole set of legacy tests are
ran using the classic parser, regardless of the normal configuration
parameter. There was something else that needed changing to get the
legacy tests to use the ast parser.
Again, I'll check this later on today once I get back to my machine.
Sent from my iPhone
On 23 Apr 2009, at 00:39, Fabio Maulo <[email protected]> wrote:
ABCProxyTest.testOneToOne() (JAVA)
"from E e, A a where e.reverse = a.forward and a = ?"
The test is the same in NH.
It should work in NH too.
2009/4/20 Ayende Rahien <[email protected]>
Because that would only end up creating more confusion.
On Mon, Apr 20, 2009 at 10:35 AM, mjcoder <[email protected]> wrote:
I'm also just a user and would prefer using the new AST parser
(because it allows DML statements). However, why don't you create two
downloadable packages? One with the old parser as default and one with
the new parser as default and let the downloader decide?
On 17 Apr., 22:22, Fabio Maulo <[email protected]> wrote:
> And which is the difference with have the new AST parser as
default ?I
> mean...
> "if you want to get the OLD parser...."
>
> IMO the scenario should be:
> A team download the new version, they have the new AST parser
working by
> default.
> The team run all tests in their development environment, if all is
working
> they will do the same in production (or QA etc.).
>
> 2009/4/17 Matt <[email protected]>
>
>
>
>
>
> > I'm just a users here...
>
> > IMO, having new code like this set as the default parser is
risky. I
> > don't see a problem keeping the default parser for now. Most on-
the-
> > edge teams will switch over to the new parser anyway, but those
who
> > are unsure or frankly don't know anybetter won't be open to the
> > possibility of new bugs in their production code. Of course,
moving to
> > new versions of anything opens you up to bugs.
>
> > If you want to get the new parser "battle-hardened", I'm sure most
> > groups will switch to it in their development environemnts and
once
> > their sure it works, they'll do the same for production.
>
> > +1 for keeping the classic parser default (for now)
>
> > On Apr 17, 7:34 am, "Richard Brown \(GMail\)"
> > <[email protected]> wrote:
> > > Just wanted to add my 2 pence to the discussion ... (sorry if
it's not
> > appropriate)
>
> > > +1 on making the AST the default parser for 2.1GA because ...
>
> > > 1. I'm not sure there are sensible criteria that I (as a
user) can apply
> > to choosing the parser, other than that the NH tests pass/fail
(or my
> > system's tests pass/fail). Asking me which (in general) should
be default
> > is not something I have enough information to decide;
>
> > > 2. From developing code on the NH side of things, I'm not
sure I value
> > correctness over maintainability. I would rather have clean
maintainable
> > code with a couple of bugs (cos that's easy to fix), than have
mostly stable
> > code that's hard to fix bugs in or enhance. Having glanced at
the AST code,
> > it seems infinitely easier to maintain (specifically I was
looking at query
> > parameters where the AST stores them (correctly) in the query,
while the
> > existing parser has them spread out in various bits of the code) -
> > ultimately I think that's the best criteria to use, making it
the obvious
> > choice for the default.
>
> > > 3. If the tests are all going to run with the AST parser,
that makes
> > supporting the legacy one harder (which compounds point 2).
>
> > > And of course ... all of this is just my humble opinion.
>
> > > Cheers,
> > > Richard
>
> > > From: Fabio Maulo
> > > Sent: Thursday, April 16, 2009 6:39 PM
> > > To: [email protected]
> > > Subject: [nhibernate-development] Re: HQL AST Parser
>
> > > 2009/4/16 Hadi Hariri <[email protected]>
>
> > > No I haven't tried it yet. I mentioned that we can port two
of our apps
> > to use the new parser, but haven't yet.
>
> > > don't worry before have a problem to be worried; the software
can be
> > fixed ;)
> > > I'll try the new parser with some real-world application too.
> > > --
> > > Fabio Maulo
>
> --
> Fabio Maulo
--
Fabio Maulo
