Hi Harald Re: dismissing L2S. I didn't intend to suggest you didn't think about it. It's just that everyone seems to agree that the L2S behavior is dumb in some cases (like the difference between x == null and x == param, with param being null), when there's really just a documentation problem. (ok, it's not ideal anyway, but an understandable trade-off.)
You seem to have a very consistent model here, I just wanted to point out that it doesn't go without disadvantages either, and that the L2S way does make sense too. (No, I don't think they ever published their reasoning, like I said I just made assumptions. Seems obvious though.) Now I'm not going to keep arguing about the right way to do it, it's the NH team's call. (There seems to be little discussion here though. I'd think the general semantic approach of a LINQ provider - C# like L2O or SQL/HQL like L2S - would be something the whole team wants to agree on. Seems like something that should be settled before getting into details with tricky stuff like the || semantics.) Anyway, I do appreciate your structured approach. Thanks for the discussion! Cheers, Stefan > -----Original Message----- > From: [email protected] [mailto:nhibernate- > [email protected]] On Behalf Of Harald Mueller > Sent: Wednesday, April 20, 2011 5:49 PM > To: [email protected]; nhibernate- > [email protected] > Subject: Re: RE: RE: RE: [nhibernate-development] NH-2583 - Query with > || operator and navigations (many-to-one) creates wrong joins > > Hi Stefan - > > > I don't see why A = B is such a strange SQL statement for you. > > Yes, I know. But let's skip this, ok? I think the best thing is that we > agree to disagree that my premise "if it behaves different from Linq, > it is a smell/bug/strange-descision-to-be-discussed" is valid. > > > You don't > > have to use navigation or the "join" operator, you might use a where > clause. > > And you don't have to restrict yourself to a primary key on either > side. > > How about A.C_ID = B.C_ID without actually including C in the query, > and > > both C_ID columns being nullable? Would you want to write A.C.ID == > B.C.ID && > > A.C.ID != null? To see this get expanded to ... I don't even want to > write > > it down ;-) > > Interesting. The expression language I have designed (5 years ago) does > not have a join - only navigation. At the few places where such "non- > navigational joins" are needed, people wrote a .Any or .Exists (and SQL > Server optimizes this to a join anyway). > > But this is no real argument in the case of NHibernate, which has to > work in a much more open environment than our framework. So yes, you > are right. > > > I'm only surprised that the L2S teams design decisions are so easily > > dismissed. > > I don't think that I ever dismissed them easily. I "dismiss" them after > much thinking and discussing and writing examples and texts. And I try > to explain my arguments by explicitly stating assumptions like (BEHAV- > 1) etc. in my text. And I still see discussions as that with Patrick > and you as a good reason to *implement* it along the lines of the > community (e.g. you). I still "reserve the right" to (try to) argue > along more purist (in my opinion) lines, > > BTW, I have not seen such a text from the Linq2Sql team - only a > practical explanation that bypasses many interesting semantical > concepts and questions. If such a text exists, I have missed it - my > fault! If not, I would claim that their decisions lack at least some > conceptual support (other than "we did it, they use it, they dont > complain, so it must be right" - but this was true even for the most > outrageous COBOL and PL/I dialects - which still didn't make them well- > designed languages). > > I still hope that the patch for the || operator that Patrick has now > committed with his additions for missing features makes you happy - > because now || behaves a little more like Linq than before :-) > > Best regards > Harald > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
