"Can't we tunnel this shared misery towards MS to fix their cruft and let them write a generic api we can work with? I mean, every linq provider writer fights with this mess. :)"
I couldn't agree more ! Selon Frans Bouma <[email protected]>: > > > VB.NET always adds the projection of a groupby query in the > > > call expression to GroupBy, C# compiler doesn't. This also creates > > > cumbersome code to obtain the real source of the groupby. I still have > > > headaches thinking about it... ;) > > > > I'm currently implementing GroupBy support in re-linq's new SQL backend. > The > > backend is mostly feature-complete for now (and for SQL Server), the only > > important thing still missing is groupings-coming- via-subqueries, which > I'm > > working on right now. Just wanted to say that I share your headaches... > > Can't we tunnel this shared misery towards MS to fix their cruft and > let them write a generic api we can work with? I mean, every linq provider > writer fights with this mess. :) > > Recently I exchanged some email with a VB.NET PM and it became clear > MS focuses on the 'code level' experience (;)) so it shouldn't matter if you > run the query in memory or in a db: the behavior should be the same. That's > of course nonsense, as in many cases Linq queries aren't convertible 1:1 to > SQL and also nullability behavior of VB.NET for example makes no sense > inside a DB (see below) > > tl;dr: it's a mess and it won't change. > > > Of course, re-linq's front-end (which is what NHibernate uses) doesn't > > provide support for most VB-specific quirks - in the end, the back-end > > (NHibernate) must be able to transform the constructs into the target > > language (HQL). > > In general that's also the right thing to do. The problem with for > example an extra .Select(x=>x) call is in the way scopes and projections > dictate how nested SQL queries are merged into one another. For example if > you see a .Select(x=>...) you know it's a projection and thus a scope marker > for aliases, and you need to threat the query as a nested query if it's > refered by others. > > So it's key to strip these out early on. It's just that if you don't > know these things occur, the user in the end will do the discovery the hard > way: with a crash :) > > an hour ago I found out that: > ' VB.NET: > Dim q = From c In metaData.Customer _ > Where c.Country="USA" _ > Select c > > Dim count = q.Count() > > is different than: > // C# > var q = from c in metaData.Customer > where c.Country=="USA" > select c; > > var count = q.Count(); > > as VB.NET introduces a '.Select(x=>x)' before the Count(), wrapping > the whole query into a derived table / subselect without a single reason. > > > > The useless coalesce statements added by the vb.net compiler > > > are better stripped out as well, because they cause complex SQL which > > > is unnecessary. > > > > I didn't know about those. When do they occur? > > every time you compare with a nullable field. This is because in > VB.NET comparisons with Nothing (null) is different than in C#. To be able > to have the same nullability comparisons in the DB as in memory (the earlier > mentioned 'query has to run equally in memory as in the db') the compiler > introduces coalesce statements into the expression tree. If you don't strip > these out, you'll end up with SQL calling COALESCE() a lot, causing > performance loss. > > The statements are useless inside a DB, as nullability inside a DB > is treated differently than in VB.NET / in memory, and even different per > database (sort order for NULL, NULL is / isn't a unique value in a UC etc. > etc.). > > Good luck :) > > FB > > > > The rest of my answer was so long I turned it into a blog post: > > <http://www.re-motion.org/blogs/mix/archive/2010/07/16/making-it-hard- > > to-implement-language-compatible-linq-providers.aspx>. > > > > Regards, > > Fabian > > > > -- > > 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. > > -- > 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. > > -- 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.
