And what you said is only a part of the story... the other part is: even when a LINQ expression does not fail have, will the expression translated into a efficient SQL?
HQL and Criteria was designed to be translated to SQL, they are specific OO queries for persistence. If what you need is only OO-strongly-typed-and-strings-free-resolved-by-C#-compiler queries LINQ is a good option. HQLs, wrote in mappings, are "only" OO-resolved-by-NH-compiler (at BuildSessionFactory). In NH you can map and query private fields or even map and query properties and collections not presents in your domain... without talk about that you can map, query and persist artifacts without have a single class (we have full support of dynamic entities). btw... when you have so many options to query your domain there is no reason to limit your options to once. On Wed, Jul 21, 2010 at 12:27 PM, Frans Bouma <[email protected]> wrote: > I think (but guessing here) what Mike means is that in case of Linq: when > something is fixed, another query which worked (in his code!) now fails. > Likely this is overexxagerated, but it's very possible, as Linq has many > many use cases (as in: infinite) and queries which are possible, and my > experience is that every single query could fail due to a slightly > different > expression tree, which might have expressions left in it after a given > stage, causing crashes later on. A fix in a linq provider usually means > that > a conversion of a subtree is changed so _that_ particular subtree results > in > an expected subtree, but if the subtree is slightly different (very well > possible, e.g. some lame Convert() expression is present in a query), the > fix might skip the subtree altogether and the query ends up broken. > > You can't simply test for this with unit tests. MS has (of what I heard, > after I asked for them ;)) several million tests for linq to sql and they > still occasionally find bugs. > > What users of a Linq provider should understand, but often they don't, is > that there will be no point in time where a linq provider works properly in > all cases: it WILL fail, no matter how much effort one puts into it, in > edge > cases. With other techniques, like string based query systems, predicate > object based systems etc. you can write straight-forward code which > eliminates almost all odd cases and you can test these systems properly. > With linq expression trees, this isn't the case as the expression tree > isn't > an AST you transform, it's an object graph with a web of references. > > FB > > > It's dishonest to say that for every new issue fixed, an old one is > broken. > > NH doesn't accept bugs without failing tests. Once a test passes, it is > > never allowed to break again. The backsliding you have suggested simply > > doesn't exist. > > > > In any case, if you are using NH in a way that doesn't have a test, you > are > > welcome to submit bug reports with failing tests to JIRA. > > > > Thanks, > > Jason > > > > > > On Wed, Jul 21, 2010 at 9:19 AM, Mike Katchourine < > [email protected]> > > wrote: > > > > > > To me the most important aspect of the new release is the LINQ > > provider rewrite. > > > > LINQ is now a non-negotiable part of programming in .NET. > > > > LINQ support is the weakest point of NHibernate, and it detracts > from > > its otherwise awesome qualities. Current NHContrib version of the > > LINQ > > provider is broken in many fundamental areas - grouping, joining, > > comparison e.t.c. Using either HQL or criteria API to plug those > > areas > > results in inconsistent bulky codebase that is hard to maintain. > > > > I can't in all conscience use the trunk, as Fabio suggests. Tried > it > > before. For all the assurance that nothing gets contributed to the > > trunk if it fails a test, the reality of the situation is, > effective > > full coverage unit tests can only be produced from sufficient > > exposure > > to real life production environments, and that just doesn't happen > > until the software is officially released. Especially with the LINQ > > provider, for every 1 problem solved 1 problem that was solved > before > > is now broken, so I would much rather wait. At least I KNOW what's > > broken in the 2.1 LINQ provider now so that I can avoid it. > > > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > > <mailto:nhusers%[email protected]<nhusers%[email protected]>> > . > > For more options, visit this group at > > http://groups.google.com/group/nhusers?hl=en. > > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/nhusers?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- Fabio Maulo -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
