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
