I'll with you... here is 03:08am... see you in few hoursBasically there are some problems with filters and select count(*) from Bar as bar, bar.Component.Glarch.ProxyArray as g
The bar.Component.Glarch.ProxyArray is a collection and should be work. I'm checking all failing test watching H3.2.6 and H3.3.1 test; if the test exist there should be work in NH too. Btw, Steve, what I need is only the first help and you can begin the LINQ ExpressionTreeTranslator 2009/4/23 Steve Strong <[email protected]> > 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]>[email protected]> > >> Because that would only end up creating more confusion. >> >> On Mon, Apr 20, 2009 at 10:35 AM, mjcoder < >> <[email protected]>[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]> >>> [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 > > -- Fabio Maulo
