So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Frans Bouma — Sat, 17 Sep 2005 12:44:28 GMT

All nice and dandy, but you most of the time will have to define types anyway, for the simple reason that the place where you READ data isn't always (most of the time) the place where you consume data. This means that where you consume data you call a method which retrieves the data for you (example: gui calls BL method).

Though in the BL method, you can use 'var' all you want, but you can't return it from the method, the method has to have a strong type. Which means that I have to define the type anyway.

I'm developing O/R mappers for more than 3 years now and I know the necessity of 'var' seems to come from the fact that a dynamic list has to be stored in a statically defined type, and 'var' 'solves' that'. But only partly as I described above.

I more and more get the feeling this 'var' construct is only useful when you directly read the data from the DB in your GUI tier for example. I don't know if Microsoft actually investigated use-cases for this, but I know from my long experience with O/R mapper code and the people who use these things, they absolutely want to separate the data usage tier from the data producing tier, i.e.: they want to avoid at all costs that a GUI developer is able to make shortcuts and read/write to the db directly, thus bypassing BL code.

We can discuss this deeper at the summit in a few weeks but I'd like to point out that it looks great at first, this 'var', but the more I think about it, it starts to look like a nice thing to demo and to use in small petprojects but is completely useless in multi-tier applications.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Ayende Rahien — Sat, 17 Sep 2005 15:13:24 GMT

I absolutely agree about var not being nearly as useful as it can be.

Beyond that, about DLinq, are the queries being remoted & executed there, or is an SQL statement is prepared from the expression tree and sent to the database?

My understanding was that it is the later case, not the first one, but you post seems to say otherwise.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

senkwe — Sat, 17 Sep 2005 20:21:21 GMT

In your last two code samples, I take it there is a comma missing between c.Name and Orders?

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Douglas McClean — Sat, 17 Sep 2005 22:03:40 GMT

Cyrus,
I like this LINQ stuff a lot except for two things:

1) DLINQ is great, but it is unfortunate that the object-database mapping metainformation has to live on attributes of the objects. This is unfortunate because I might use the same business type to map to multiple data stores (e.g. to a database for persistent storage and to XML for messaging, or even to a different database on the server vs. the smart client).

2) It seems that LINQ query engines have to compile the queries to the underlying query language every time they are executed, which can't be a cheap operation. This is because the query is bound with what would ordinarily be considered query parameters very early on. Thus if I declare a query to find all of a customer's orders based on the customer ID, it seems like DLINQ will have to recompile that query to SQL at each execution (because it will be a different query, because the customer ID will be different in the general case). It seems that introducing something like QueryParameter<T> would allow the query to be defined with a "blank" to be filled in later, precompiled (by calling some method that instructs the query to figure out it's SQL, and keep that in a cache, and maybe even cache a DynamicMethod for mapping types in and out), and then used multiple times later with different values. It seems like (not having measured) that this would be likely to be a significant performance win in many cases. It also seems that it might allow for earlier (compile time or static analysis time) checking of queries for satisfiability against the database metainformation.

Keep up the good work!

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Cleve Littlefield — Sun, 18 Sep 2005 00:15:23 GMT

I agree with the last comment about caching the query, for two other reasons.

By parameterizing the query you can also get a cached execution plan and also be more secure because the dynamic data is passed as parameters.

I hope that string concatenation is not the method used to build the final query. The dynamic pieces of the where need to be parameters and the whole query executed using sp_executesql for security.

For a hierarchical query, how do we tune in case the SQL it generates is not optimal? We need a QA like tool that shows the final query output, shows queryplans, and lets us optimize.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

CyrusN — Sun, 18 Sep 2005 04:42:45 GMT

Ayende: "Beyond that, about DLinq, are the queries being remoted & executed there, or is an SQL statement is prepared from the expression tree and sent to the database?

My understanding was that it is the later case, not the first one, but you post seems to say otherwise. "

What's the difference? It's an implementation detail that will be determined based on which vendor you choose. Some implementations might generate SQL and execute it on the server. Some might remote the entire expression object over to your server and have it execute in say a CLR you have on that side. Both are possible.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Firedancer — Sun, 18 Sep 2005 10:45:04 GMT

It really looks complicated to me. Given a choice, I would prefer not to learn a third language to integrate two languages. SQL can really be complex. Also, how do we represent OUTER JOINS or CROSSJOINS in LINQ?

Looking at this, I will prefer the traditional SQL in Stored Procedures and access it via ADO.NET. Much easier to work on. Also, I think OR Mappers are easier to understand and more usable. Not sure about others.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Sun, 18 Sep 2005 22:48:22 GMT

Heres a question about DLinq:

given a query, such as:

var q =
from c in customers
where c.City == "Seattle"
select new NameAndAge(c.Name, c.Age);

Now, normally this is converted into an expression using extension methods from the System.Query namespace.

What would happen if a completely different implementation of those extension methods was imported instead of System.Query. Is DLinq pluggable to that extent?

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Mon, 19 Sep 2005 11:07:16 GMT

a question on anonymous types...

I kinda like this new notation, but only as a way of bringing together various query results. Clearly, these anonymous types arent usefull beyond the scope in which they are created, except as a data-holding class that can be reflected over.

It would be usefull to be able to constrain these anonymous types to be immutable and/or structs.

var cust = [Immutable.Class] new { Name="foo", Address="bar"}

var cust = [Immutable.Struct] new { Name="foo", Address="bar"}

or something like that.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Mon, 19 Sep 2005 15:09:47 GMT

One of the more interesting capabilities of SQL is the ability to consisely join two tables:

select * from foo join bar on foo.a = bar.a

The result of this join will include all the properties of foo and bar. If a new property is added to foo or bar, queries such as the one above dont need to be changed; the added properties propagate naturally through to the result.

With LINQ, everything is strongly typed, and as far as I can see, all projections need to be fully specified. If a new property is added to a table, the programmer has to find all references to that table and update any projections in any queries it might participate in.

Could be nasty.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Jared Nuzzolillo — Mon, 19 Sep 2005 19:17:28 GMT

"This new query syntax is in fact just syntactic sugar that uses patterns to transform itself into the *exact* same C# query that i listed above."

Will that pattern-transforming capability be exposed to the programmer, or is that an implementation detail? If you are here revealing that, in C#, metaprogramming will finally be possible, this particular SQL example is only a tiny glimpse of the many new possibilities.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Sean Chase — Mon, 19 Sep 2005 21:49:06 GMT

Cyrus, this is very cool stuff for sure! Honestly I share the same concern as Frans Bouma who has a really great O/R mapper product (LLBLGen Pro) that I've been using over the last several months for a client's project. He has nailed an important issue: that most of the time there is either a logical or physical boundary between the data reader and data consumer. For example, imagine a common assembly to hold classes like Customer, Order and the UI calls a BL layer which both reference common.dll to use those entities. LLBLGen Pro uses an adapter to do this. I would absolutely love to see DLINQ provide this kind of model. Of course there is a market for the "unlayered" model that's being demo'd today just like there is a market for people using the SqlDataSource control in ASP.NET with literal T-SQL values embedded right in the page...but that kind of approach is almost useless to me in most cases. Probably a better value for mort. :-)

Great post!

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

kfarmer — Mon, 19 Sep 2005 22:19:26 GMT

damien: "With LINQ, everything is strongly typed, and as far as I can see, all projections need to be fully specified. If a new property is added to a table, the programmer has to find all references to that table and update any projections in any queries it might participate in.

Could be nasty.
"

IMHO, shouldn't we consider this to be a view into the database? Just because a column is added to a table doesn't mean we need to add it to the query. It's up to the background objects to determine whether or not a column is required, and up to the developer to specify the ones he's actually interested in dealing with.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Mon, 19 Sep 2005 23:06:46 GMT

kfarmer: I take your point, but this is an example of a philosophical mismatch between a LINQ query and an SQL query.

As a C# developer, I am comfortable with explicitly declaring all the properties of interest, however, SQL allows for those properties to be dealt with in bulk. Tutorial-D (Date's alternative to SQL) allows more sophisticated operations on those bulk properties, such as S{ALL
BUT CITY, NAME}.

Operations for dealing with properties in bulk constitute a kind of dictionary algebra, with support for renaming, merging, and so forth. A general solution in this domain is messy, however you cut it.

Im not sure this is a problem, but if it is, its a messy one.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Tue, 20 Sep 2005 09:33:33 GMT

Jared:

"Will that pattern-transforming capability be exposed to the programmer...?"

Yes it will - if you assign a lambda expression to a variable of type Expression<T> you can then manipulate the expression tree to your hearts content.

Not sure how select expressions are handled.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

duncan — Tue, 20 Sep 2005 10:52:14 GMT

In your code snippet:

var q =
from c in customers
where c.City == "Seattle"
select new {
c.Name,
Orders =
from o in c.Orders
where o.Cost > 1000
select new { o.Cost, o.Date }
};

Why is there no 'var ' needed before 'Orders = ' ?

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

SlyW — Tue, 20 Sep 2005 21:44:05 GMT

duncan: Because it is inferred from the "select new { o.Cost, o.Date }" portion of the 'subselect'.

That is my understanding of it.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

kfarmer — Wed, 21 Sep 2005 00:06:58 GMT

damien:

I think that's because the philosophy of LINQ isn't *about* SQL databases: those are a side-attraction.

I think Microsoft made a mistake in focussing so much on making the SQL folks comfortable that they've now got a very hard time ahead in explaining the differences between the two. Part of that mistake was in publishing C-omega: everyone fell in love with it, even though it had some serious troubles in dealing with embedded SQL. Now everybody wants C-omega, despite the lower degree of applicability.

I don't have my LINQ machine in front of me, but have you tried just selecting the item? Something like:

from c in Customers
where c.name = 'Bob'
select new { Customer = c, IsBob = true }

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Wed, 21 Sep 2005 01:02:33 GMT

That query does work, I just tested it, but wont work in a regular database.

I think that youre right about LINQ not being about SQL databases.

A great part of our jobs as programmers is writing queries over our data structures, and the LINQ framework does a lot of that work for us.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

damien morton — Wed, 21 Sep 2005 02:05:35 GMT

Oh cool!

You can define your own relational operators, such as Where() specialised on types derived from IEnumerable<T>.

This is a somewhat inane example, but compare Where() defined for IEnumerable<T> and an equivalent Where() defined for IList<T>. All you need to do is ensure your new extension method is available and type-resolution will select the most specific overload.

public static IEnumerable<T> Take<T>(this IEnumerable<T> source, int count)
{
if (count > 0) {
foreach (T element in source) {
yield return element;
if (--count == 0) break;
}
}
}

public static IEnumerable<T> Take<T>(this List<T> source, int count) {
for (int i = 0; i < count; i++)
yield return source[i];
}

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

kfarmer — Wed, 21 Sep 2005 03:10:21 GMT

I think you can also do something like:

Expression<Func<double, double, double>> Between(this double x, double low, double high) = (double low, double high) => (low < x && x < high);

var foo = Customers.Where(c => c.Age.Between(18, 24.5));

Lambda's are fun creatures to play with.

Again, my machine's at home...

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

CyrusN — Wed, 21 Sep 2005 03:21:10 GMT

Firedancer: "It really looks complicated to me. Given a choice, I would prefer not to learn a third language to integrate two languages. SQL can really be complex. Also, how do we represent OUTER JOINS or CROSSJOINS in LINQ? "

That's why we gave you a choice. You don't have to use this if you don't want to.

"Looking at this, I will prefer the traditional SQL in Stored Procedures and access it via ADO.NET. Much easier to work on. Also, I think OR Mappers are easier to understand and more usable. Not sure about others. "

Again, that's why there's a choice.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

CyrusN — Wed, 21 Sep 2005 03:22:49 GMT

Damien: "Heres a question about DLinq:

given a query, such as:

var q =
from c in customers
where c.City == "Seattle"
select new NameAndAge(c.Name, c.Age);

Now, normally this is converted into an expression using extension methods from the System.Query namespace.

What would happen if a completely different implementation of those extension methods was imported instead of System.Query. Is DLinq pluggable to that extent? "

The "from" syntax has *nothing* to do with System.Sequence. It is just syntactic sugar that converts it to a pattern. i.e. .Where, .Select.

So if you're using some other types that define their own Where/Select methods, then you'll be fine. the "from" comprehension will just end up binding to those.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

CyrusN — Wed, 21 Sep 2005 03:24:26 GMT

Damien: "a question on anonymous types...

I kinda like this new notation, but only as a way of bringing together various query results. Clearly, these anonymous types arent usefull beyond the scope in which they are created, except as a data-holding class that can be reflected over.

It would be usefull to be able to constrain these anonymous types to be immutable and/or structs.
"

Right now we're just showing a preview of what we're working on. there are currently limitations in place in that preview (like not being able to pass "Var" out of a method. We're actively investigating different approaches to this problem (such as being able to define anonymous types easily so that you can pass them around.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Ruben — Fri, 23 Sep 2005 00:03:31 GMT

Is it just me, or would the XQuery-like syntax

var q = for c in customers
....... where c.City == "Seattle"
....... select c.Name;

not be more C#-ish? I could even go for

var q = for c in customers
....... where c.City == "Seattle"
....... return c.Name;

But that would probably be a little confusing. Replacing from with for saves you a keyword, and could silence all the complaints about wanting SELECT FROM instead of FROM SELECT.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

CyrusN — Sun, 25 Sep 2005 06:21:01 GMT

Ruben:

"Is it just me, or would the XQuery-like syntax

var q = for c in customers
....... where c.City == "Seattle"
....... select c.Name;

not be more C#-ish? I could even go for"

That would be fine.

"var q = for c in customers
....... where c.City == "Seattle"
....... return c.Name;"

I like that less. The return would be extrmely confusing.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

kfarmer — Tue, 27 Sep 2005 00:58:37 GMT

How about

"for c in customers
where c.City == "Seattle"
yield c.Name;"

Yield fits in with the generator idea that this is making use of.

One might also use foreach instead of for, if an unambiguous syntax can be had in that case.

re: So what's the deal with this whole C# 3.0 / Linq thingy? (Part 2)

Mark Blomsma — Sun, 23 Oct 2005 10:29:31 GMT

The scope of 'var' obviously needs to be greater than just within a method.

Some queries will get to be very long. How can you refactor this if your scope is limited?

linq select column as literal

linq select column as literal — Mon, 04 Aug 2008 04:18:05 GMT

PingBack from http://yasmin.getyourfreefitnessvideo.info/linqselectcolumnasliteral.html

Cyrus Blather So what s the deal with this whole C 3 0 Linq | Cellulite Creams

Cyrus Blather So what s the deal with this whole C 3 0 Linq | Cellulite Creams — Tue, 09 Jun 2009 06:13:38 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=771

Cyrus Blather So what s the deal with this whole C 3 0 Linq | storage bench

Cyrus Blather So what s the deal with this whole C 3 0 Linq | storage bench — Fri, 19 Jun 2009 11:07:00 GMT

PingBack from http://thestoragebench.info/story.php?id=2487