> > 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.
