Partager via

Ordering of Commands – What do you think?

  • Article

Some of our customers write code like this:

ctx.AddToCustomers(customer);
ctx.AddToProducts(product1);
ctx.AddToProducts(product2);

And expect the Entity Framework to issue 3 insert commands in the same order.

Today the EF doesn’t preserve this sort of ordering.

Instead the order inserts/updates and deletes are made in the Entity Framework is based mainly on local inter-dependencies.

For example if you insert a new Product in a new Category we have to add the Category before the Product .

This means that if you have a large set of changes there are local ordering constraints that we must satisfy first, and these rules can easily be in conflict with order things actually happen in the ObjectContext.

For example if you do this:

 ctx.AddToProducts(
   new Product{
      Name = "Bovril",
      Category = new Category {Name = "Food"}
   }
);

the effect is that the Product is added (to the context) first and then when we walk the graph we add the Category too.

i.e. the insert order into the context is:

 Product
Category

but because of referential integrity constraints we must re-order like this before attempting to insert into the database:

 Category
Product

So this kind of local re-ordering is kind of non-negotiable.

However if there are no local dependencies like this, you could in theory preserve the order of changes.

Today though we don't track 'when' something was added to the context or even when something gets modified, and for efficiency reason we don't track entities in order preserving structures like lists. So currently we can't preserve the order of unrelated inserts, updates and deletes etc.

My question to you is how important is this?

Would you like to see us preserve your ordering as much as possible?

Comments

  • Anonymous
    June 05, 2009
    Hmm... The only "resonable" reason that defining object dependency would be valuable is when there are constraints on DB that cannot be expressed in EDMX because of some reasons (partial mapping? procedures? triggers?). In such case having method on object/context like obj1.DependsOn(obj2) will be sufficient.IMHO...
  • Anonymous
    June 05, 2009
    Wojciech,I like your obj1.DependsOn(obj2) idea.very interestingAlex
  • Anonymous
    June 05, 2009
    we need ordering!!Keep it simple.
  • Anonymous
    June 06, 2009
    Thanks for the feedback Vijay
  • Anonymous
    June 07, 2009
    Can't think of a single reason why ordering would be important.  EF is a way of hiding the complexities of the storage mechanism, so why would I want to use EF if I have specific storage-mechanism requirements?FWIW I think you're right to not bother preserving order.