How to avoid that all new instances are committed to the database RRS feed

  • Question

  • Hi,

    Let me start by saying that I absolutely love LINQ - being able to automatically make you entire database object oriented is fantastic. However I am a little confused about something. Lets say I create a new object somewhere in my program, like Customer c = new Customer(). Upon the next call to SaveChanges on the ObjectContext, that new object will be saved to the database just as you would expect, but what if you dont want that to happen?

    Say you invoke a webservice and parses the response into a list of customers. Some of them will end up in the database and some wont - but the user should sort the right ones out through a proper user control. My problem is that if the webservice returns 10 customers, I create 10 objects which all ends up in the database even though I only wanted the subset that the user selected to be saved - how do I do that?

    I can think of about a hundred workarounds for this problem but they all involve the use of some auxiliry object type - and as far as I am concerned, the whole idea with LINQ is that you take full advantage of the types that the framework generates for you. If you end up writing just as many classes yourself as you have in you database with exactly the same properties, then where is the benefit?

    So I am looking for a best practice here :)


    Wednesday, July 20, 2011 12:44 AM


All replies

  • Just creating an instance of an entity class will not attach it to the ObjectContext. Only objects attached to the objectcontext will be saved by SaveChanges.
       Cool tools for Linq-to-SQL and Entity Framework 4:
     huagati.com/dbmltools - Visual Studio add-in with loads of new features for the Entity Framework and Linq-to-SQL designers
     huagati.com/L2SProfiler - Runtime SQL query profiler for Linq-to-SQL and Entity Framework v4
    Wednesday, July 20, 2011 2:11 AM
  • This code will create a new row in my Address table (the former example was with customers, I know, but the same principle applies)


                DatabaseEntities entities = new DatabaseEntities();

                var query = from city in entities.City where city.Zip == "XXXX" select x;


                Address addr = new Address();

                adr.Road = "XXXX";

                adr.No = "XX";

                adr.City = query.First();



    Wednesday, July 20, 2011 9:29 AM
  • Sorry "select x" should of course have been "select city"
    Wednesday, July 20, 2011 9:30 AM
  • So the link to the ObjectContext is established through the assignent of the City object to Address, I guess.

    But creating entity objects without assigning the basic properties seems useless, so I dont quite understand why the framework is designed this way. 
    Wednesday, July 20, 2011 10:24 AM
  • Didnt Detach work for you? i didn't very understand your means, but for my experience, if some objects which i previously loaded from the context, i generally explicitly attach this object to context because i should let the context know that it changed. How do we know which properties were changed?

    We said that the EF needed not only the original concurrency value but also the list of modified properties.  The proposed solution to this problem is just to mark every property on the entity as modified whether it was modified or not.  This approach won’t work for everyone, but it’s actually effective in a surprising number of cases.  The EF uses the list of modified properties in order to determine which values to send to the database in its update statement.  Having a shorter, more precise list will reduce the wire traffic to the database, but on the other hand if different properties are updated in different transactions, then having the more precise list may actually cause worse performance once the operation gets to the database because it will produce fragmentation in the query plan cache.  Sending the same set of properties every time will sometimes produce much better performance even though it means sending more data on the wire.  Whether or not this is the right trade-off for your application is something that will require profiling to determine.

    You can check this link. http://blogs.msdn.com/b/dsimmons/archive/2008/10/31/attachasmodified-a-small-step-toward-simplifying-ef-n-tier-patterns.aspx



    Just a newbie for everything.
    Friday, July 22, 2011 8:47 AM
  • Detach() works for me, yes, but I dont know how to attach it again. Calling Attach() with the object return an error "An object with a null EntityKey value cannot be attached to an object context" and I dont know how to set that key.

    AttachTo("Address", adr) where adr is an address-object doesnt work either.

    Actually what I want to do is quite simple: I want to be able to create new entity objects without having these objects saved to my database on the next call to SaveChanges if I didnt explicitly attach them to my object context.

    Next, I want to be able to iterate through a list of entity objects and save each object to the database if it doesnt already exist (thats is, if its not attached to the object context).

    I want to do these things independently of each other.

    It is possible that I'm using the LINQ framework in way that its not designed for - in that case I am naturally interested in knowing how it is intended to be used :)
    Saturday, July 23, 2011 1:23 PM
  • Hello,

    Have you tried using AttachTo method to attach a specific entity set in a object context or a null. Please check this document for more information about AttachTo http://msdn.microsoft.com/en-us/library/system.data.objects.objectcontext.attachto.aspx Like:

    YourEntityName.AttachTo("Name", dbName); 

    Best Regards,

    Larcolais Gong[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, July 24, 2011 3:04 PM