Open MikaelEliasson opened 9 years ago
Good idea! Syntax might be a bit verbose but also might be the least verbose possible.
My first try was to build it with
x => x.Reads = x.Reads + 1
The problem was that Linq didn't support assignments in the inline version.
The biggest problem with that syntax is that it only allows updating a single property. If it's bound to SaveChanges it could simply allow multiple Update() to fix that. In my code the Update call triggers the Sql query. If using that approach I would either add a defered Set(propSelector, update) or create an overload for Update that can take a list of "ColumnModifications".
It's indeed a tricky situation with which method to start the query, as you need more information appended after 'Update()' while it feels natural to start the update with 'Update()'. It is likely solvable with a myriad of lambdas but I've learned that although it works these kind of APIs aren't loved very much. Perhaps an UpdateSpecification object can be used and passed to the method? e.g.:
ctx.Customer.UpdateDirectly(c=>new UpdateSpecification() { /* init specification */});
With a specification it's possible to add whatever operations needed.
CodeSmith DataContext extensions already do something like that and that's the syntax they use.
To remain consistent with SubmitChanges
, I would use .SubmitUpdate(c => new UpdateSpecification() { /* init specification */});
.
Similar to #16 Delete by Query but let you update instead. See that issue for more info.
I'm not going to suggest a syntax here, just show what EFUtilities does.
Once again the biggest problem is that aliases for joined/subqueried tables is more complicated in updates than selects.