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
