I think that I am happy enough with that, yes. I suggest we add it as non default option for 2.1, and change that to the default in vNext
On Wed, Apr 15, 2009 at 1:05 PM, Steve Strong <[email protected]> wrote: > No reason that I can think of why that wouldn't work - use the classic > parser for your regular HQL queries, and the AST parser for LINQ (under the > covers, the LINQ code is going just create the AST parser directly so the > configuration is not important). > > I think the only time you'd *have* to switch to the AST parser for regular > HQL stuff is if you wanted bulk update functionality (or any other new > function that we only add into the AST parser). > > On 15 Apr 2009, at 12:01, Ayende Rahien wrote: > > Steve, > Do we even need to make activate the new parser in order to use it? > I would assume that we can use the classic parser and still take advantage > of AST to query support, no? > > On Wed, Apr 15, 2009 at 11:07 AM, Steve <[email protected]> wrote: > >> >> 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 >> > > >
