DLinq: Demystifying OR Updates


Here is another FAQ I got about DLinq at PDC. How does DLinq handle changes to objects? How is it similar to or different from ADO.NET DataAdapter? 


Here is a quick overview of what goes on under the covers at a conceptual level:


Before objects are modified:



  • Original values are copied for

    • Detecting changes; and
    • Detecting optimistic concurrency conflicts

After SubmitChanges() is called:



  • Modified objects in the object graph are identified. This includes changes in relationships between persistent objects – whether singleton references or collections of references

    • New objects to be inserted
    • Retrieved objects to be deleted
    • Retrieved objects whose persistent members have changed

  • Changes are ordered based on foreign key constraints. DB-generated key values that propagate to foreign keys are taken into account. 
  • Insert, update and delete statements are constructed with modified current  values in the set clause and original values in the where clause for optimistic concurrency conflict detection
  • Database connection is opened and a transaction is started. The insert / update / delete statements are executed as a batch in the context of the transaction
  • If there are any errors, the transaction is rolled back. Appropriate exception is thrown (e.g. optimistic concurrency exception in case of conflicts)
  • If the transaction succeeds, the internal state of the DataContext is changed accordingly.
  • Database-generated columns like autoincrement / GUID keys and timestamps are propagated back to the objects

Of course, this is a simplified description of what needs to be taken care of in the implementation. A couple of notable things are:



  • If you use our generated code (or implement similar code), we can optimize change tracking for space and time. Essentially, it is a “copy-on-write” optimization so it avoids copying objects that are not changed and it also reduces the processing required when SubmitChanges is called. The list of objects that are changed is roughly the list of objects copied.
  • If you have created insert / update / delete methods on a class derived from DataContext (e.g. for using stored procedures), those methods are called instead of generating and executing insert / update / delete commands.

In case of DataAdapter (required for persisting changes made in DataSet back to the database), you will need to do the following:



  • Create one DataAdapter per table 
  • Create up to three commands per adapter with appropriate parameters for original values etc.
  • Execute the updates in the right order depending on foreign key constraints. You have to be mindful of the different order required for insert and deletes.
  • Flow the server-generated key values appropriately.

So DLinq does a lot of work for you and simplifies your life greatly. After all, DLinq is about raising the abstraction level and bringing it on par with what modern OO languages provide.


Comments (5)

  1. Jeff Davis says:

    This is great! It’s good to hear that you’re dealing with the full E2E flow for DB data.

  2. Mike Bouck says:

    "In case of DataAdapter (required for persisting changes made in DataSet back to the database), you will need to do the following:

    o Create one DataAdapter per table

    o Create up to three commands per adapter with appropriate parameters for original values etc.

    o Execute the updates in the right order depending on foreign key constraints. You have to be mindful of the different order required for insert and deletes.

    o Flow the server-generated key values appropriately."

    To be fair, all the above can be handled via codegen techniques automatically. I have CodeSmith templates that do this today (on Everett as well as Whidbey). The only manual step is laying out the datamodel — the rest is point and shoot. Don’t get me wrong though, I’ll be the first to get all over DLinq when its ready for primetime!

  3. Mike: Yes, who doesn’t 🙂

    (I mean: use codesmith for generating all those adapters and datasets and stuff).

    And yes, I can’t wait to see DLinq being used for real apps.

  4. Javier Luna says:

    Nice post Dinesh.

    I had developed a Business Layer Strongly Typed on DLinq with Many-to-Many support.

    Simple struct database: Users and Groups as like project sample.

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=109996

    Cheers,

    Javier Luna

  5. Dinesh.Kulkarni says:

    Mike’s comment is fair – code gen for DataAdapters does reduce complexity. But this is where the difference between builders of object model vs users of a business object model comes into picture. The DLinq story is that someone can set up the mapping once and everyone can do queries against the object model. Perhaps I will do more contrasting in a separate post.