3

Is there a way to limit the scope of SubmitChanges() to a subset of the overall data domain?

Example:

Bob intends to update a Web Order, but Alice inserted a property, unbeknownst to Bob, that updates a product price (in memory only, not pushed to DB) upon being written to. Bob considers this a travesty that should be avoided at all costs. Bob wishes he could have constrained the scope of the update to the WebOrders sub-domain.

Based upon my understanding, I have to trust that unwanted changes have not been made to other parts of the domain by other code in the application.

It would seem nice to be able to constrain the SubmitChanges() to only touch those objects from within a subset of the domain.

Brian Webster
  • 27,545
  • 47
  • 143
  • 218

1 Answers1

4

No it is not possible. DataContext is unit of work (it behaves exactly same as context in entity framework) so first of all it should not be shared between multiple user operations. Only Bob's changes should be in the context and because of that he either decides to save all changes or throw away the context (= Dispose) with all changes.

Community
  • 1
  • 1
Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • Ladislav, that's good information. However, I tried to illustrate the point that Bob cannot trust that Alice did not insert some dangerous "Price changing" code that is executed (unknowingly to Bob) when Bob updates the Web Order Properties. As a result, the last part of your answer seems a little off. However, the first part was quite helpful. – Brian Webster May 22 '11 at 08:15
  • If changes are already in the database then it is problem of concurrency. You must involve concurrency detection and catch exception that will inform Bob about changes in the database: http://msdn.microsoft.com/en-us/library/bb399373.aspx – Ladislav Mrnka May 22 '11 at 08:17
  • 1
    If changes are somewhere else in the application (not persisted) then it should be case for your business logic which must do the validation of changes prepared by Bob - it is not case for Linq-to-sql. – Ladislav Mrnka May 22 '11 at 08:21
  • Example: Alice changed the logic of the Price property of the WebOrder to change a Product Price. MyWebOrder.Product.Price = $10.00, when all Bob did was set MyWebOrder.Price = $10.00. Bob did not know that Alice caused the WebOrder.Price property to perform this change. Now, when Bob hits SubmitChanges(), it will send a bad price to the Products table. Bob only wanted to commit the WebOrder changes. – Brian Webster May 22 '11 at 08:24
  • 1
    But this can happen only if Alice and Bob shares the same DataContext instance which should never happen. There is no way to avoid it once you share the context. – Ladislav Mrnka May 22 '11 at 08:27
  • Are you sure? I don't see Alice using a data context at all. All she did was write a bit of code inside the "set" portion of the WebOrder price property. – Brian Webster May 22 '11 at 08:29
  • 1
    But how she got the order? If you read my linked answer about EF context you will see description of two patterns: identity map and unit of work. UoW means that all changes are always saved and IM means that there is only one instance per unique entity = if Bob can accidentally save Alice's changes it means that she must have the instance loaded by the same context and context track changes to that instance. Or I completely don't understand your use case. – Ladislav Mrnka May 22 '11 at 08:33
  • Ladis, I don't necessarily have a use-case yet. I'm trying to understand the technology, and this felt like a shortcoming. However, I will read up on your links which, based upon your last comment, seem to be to be project rules for eliminating this as a concern. Thanks. – Brian Webster May 22 '11 at 08:36
  • This is usually considered as concurrency. Unless Alice saves changes to the database Bob should not be aware of that (Alice can still cancel her changes) and if you use context correctly Bob should never accidentally save Alice's changes. Once changes are saved it is up to you how do you handle that data has changed in the database while either Bob or Alice worked on their changes. – Ladislav Mrnka May 22 '11 at 08:39