Please consider to extend Linq to add a new keyword "update" and "delete"

[juniorgasparotto]

hi,

Consider extending Linq to add "update", "delete", "leftjoin" functionality. This would take Linq to another level and simplify working with data from memory collections and even relational databases. I know this must be very difficult, but I see that the LINQ syntax is very exciting in the first contact, but it is disappointing when you realize that it is not what it seems to be.

[HaloFour]

You can already accomplish "leftjoin", although admittedly the syntax isn't wonderful.

LINQ to Objects is designed to operate over IEnumerable<T> which is a forward-only and read-only representation of the data. There really isn't a facility through which LINQ APIs could expose update or delete functionality for a language feature to utilize.

For DBs, that would depend entirely on the ORM. Entity Framework doesn't have bulk support built-in, but does through third-party libraries. The language can't add it without support at the ORM level to interpret the expression tree.

[juniorgasparotto]

I understand the difficulties, but shouldn't LINQ evolve alone without worrying about the Entity Framework? I see that an approximation of LINQ with the SQL syntax, even if it is in memory objects, would already make the language very attractive for programmers of other languages.

I may have a wrong view of how things are going, but I think the Entity Framework should go after LINQ and not the other way around.

Anyway, thanks for the quick and polite response.

[HaloFour]

The C# team likely wouldn't consider any changes to what would be supported by LINQ without Entity Framework committing to supporting it within the same timeframe for release. Otherwise the experience would be terrible, having a keyword that can't be used.

Either way, the functionality is already very easily accomplished through libraries. You can already do this with LINQ and Entity Framework with the library mentioned above:

var query = from user in db.Users
    where user.IsActive == false
    select user;

query.Delete();

// or
db.Users.Where(user => user.IsActive == false).Delete();

Why does this need language support?

[juniorgasparotto]

I see that mass operations for "delete" and "update" with "leftjoin" joins would bring the language an elegance and simplicity that only exists in SQL. As a "user" of the language, I'm sad to hear that LINQ has to carry EF on his back.

But I appreciate the attention

[leandromoh]

LINQ operators are not supposed to have side effects, which is where update and delete lies in.

[yaakov-h]

LINQ is a Language-Integrated Query. Update and Delete are technically NonQuery. 🙃

[juniorgasparotto]

I understand the points mentioned, but see how it would be more elegant and attractive :)

Actual:

var entities = new List<Entity>();
entities.Add(new Entity { A = "123", B = "234" }

foreach (var e in entities)
	if (e.B == "X")
		e.A = "new value";

Proposal:

update e.A = "new value" in entities where e.B == "X";

[theunrepentantgeek]

LINQ is very deliberately written top to bottom, unlike SQL, so it would be far more likely to look like this, with the update at the end:

from e in entities
where e.B == "X"
update e.A = "new value"

But, you can write this right now:

foreach (var entity in entities.Where(e => e.B == "X")) 
    e.A = "new value";

or, if you want to use the LINQ syntax:

var matches =
    from e in entities
    where e.B == "X"
    select e;
foreach (var e in matches) 
    e.A = "new value";

Elegant and attractive may be criteria that the LDM use, but they definitely use scope (how many people would use it), value (how much of a benefit it provides in each use), and cost (how much will it cost to implement).

My own belief here is that scope is small (most people would never use it, support from EF etc is unlikely), value is low (there are already good ways to achieve this with very little code), and cost is high (requires new syntax, complex compiler transformations, and lots of supporting library code).