RoMiller wrote:
If anyone is planning to tackle the code for this feature I just want to encourage you to reach out to our team for help working out how to implement it. This would be a pretty complex feature and for us to accept it back into the main code base it would need to work with the provider model etc. We're certainly on board with helping you get familiar with those parts of the code base.
I'm interested in possibly looking into implementing this in the EF code base. When creating EntityFramework.Extended, I had to wrap the update or delete in the provider generated select with a join. It would obviously be better if the provider itself could generate and execute.
Having provider support would be step one of the implementation. I assume the best way to pass to the provider would be some variation of DbModificationCommandTree? I'm not sure if DbDeleteCommandTree or DbUpdateCommandTree would work as they might be expecting a single result. What about backward compatibility with providers? Is there a way to know what the provider supports?
Integration with change tracking or local store would be nice but quite complex. I'm thinking that could be a phase 2 implementation.
Delayed execution till SaveChanges would also be nice, but again, phase 2.
What is the favored API design? I've seen several variations of APIs that do the same thing. The design I implemented in EntityFramework.Extended uses an extension method of DbSet or ObjectSet. The syntax is as follows ...
context.DbSet.Delete(whereExpression);
context.DbSet.Update(whereExpression, updateExpression);
Variation could be ...
context.DbSet.Where(expression).Delete();
context.DbSet.Where(expression).Update(updateExpression);
Or ...
context.DbSet.Where(expression).DeleteAll();
context.DbSet.Where(expression).UpdateAll(updateExpression);
thanks,
~ Paul