none
SingleOrDefault() and InsertOnSubmit() behavior RRS feed

  • Question

  • I have this oversimplified table:
    Person(
        Id int NOT NULL,
        Name varchar (20) NOT NULL
    )
    
    .....
    Id is the primary key. The table is empty.

    If I run this code:


    Person p1;
    Person p2;
    p1 = db.Persons.SingleOrDefault(r => r.Id == 1);


    if
    (p1 == null)
    { p1 = new Person(); p1.Id = 1; p1.Name = "John"; db.Persons.InsertOnSubmit(p1); } p2 = db.Persons.SingleOrDefault(r => r.Id == 1);
     
    ....
    Why does p2 equal null at the end?
    Isn't the InsertOnSubmit(p1) supposed to insert the Person object with Id==1 in the cache? and isn't a subsequent call to .SingleOrDefault on that same primary key supposed to return the cached object even before it's submitted to the database?

    It was my understanding that doing a seach using .SingleOrDefault() with the primary key scanned both the cache and the DB table.

    Thanks
    Friday, April 3, 2009 8:01 PM

Answers

  • The previous response is correct -- you do need to call SubmitChanges before this query will work. However, I wanted to clarify one thing from the original post:

    >> It was my understanding that doing a seach using .SingleOrDefault() with the primary key scanned both the cache and the DB table

    There are two issues here that I want to elaborate on:

    (1) That is correct, except in this case, the new item is not in the identity cache yet. It doesn't get inserted until after you submit the changes, or it would also have been originally in the cache if you had queried the item from the database instead of creating it on the client. The item is known to the DataContext once you call InsertOnSubmit, but it's not actually in the identity cache yet, which is the cache the query might search.
    (2) There are a limited set of queries in .NET 3.5 where the identity cache is actually searched. This *is* one of them, but there are similar queries where it wouldn't even try the cache. For .NET 4.0, we are expanding the set of queries that will attempt this client-side lookup. See http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362313 for more details. Note that this fix will not change the behavior as described in the original post -- you will still have to call SubmitChanges due to the 1st point above.

    Thanks,
    Sarah Parra
    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Carlos.V Tuesday, April 7, 2009 7:39 PM
    Monday, April 6, 2009 9:52 PM
    Moderator
  • hi,

    you must use .SubmitChanges() before p2 = db.Persons.SingleOrDefault(r => r.Id == 1);
    because up to that point, the client are working on. To receive data from the server must send the client data

    ------------------
    Getek - Türkiye
    Good Codes
    Saturday, April 4, 2009 3:07 PM

All replies

  • hi,

    you must use .SubmitChanges() before p2 = db.Persons.SingleOrDefault(r => r.Id == 1);
    because up to that point, the client are working on. To receive data from the server must send the client data

    ------------------
    Getek - Türkiye
    Good Codes
    Saturday, April 4, 2009 3:07 PM
  • The previous response is correct -- you do need to call SubmitChanges before this query will work. However, I wanted to clarify one thing from the original post:

    >> It was my understanding that doing a seach using .SingleOrDefault() with the primary key scanned both the cache and the DB table

    There are two issues here that I want to elaborate on:

    (1) That is correct, except in this case, the new item is not in the identity cache yet. It doesn't get inserted until after you submit the changes, or it would also have been originally in the cache if you had queried the item from the database instead of creating it on the client. The item is known to the DataContext once you call InsertOnSubmit, but it's not actually in the identity cache yet, which is the cache the query might search.
    (2) There are a limited set of queries in .NET 3.5 where the identity cache is actually searched. This *is* one of them, but there are similar queries where it wouldn't even try the cache. For .NET 4.0, we are expanding the set of queries that will attempt this client-side lookup. See http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=362313 for more details. Note that this fix will not change the behavior as described in the original post -- you will still have to call SubmitChanges due to the 1st point above.

    Thanks,
    Sarah Parra
    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Carlos.V Tuesday, April 7, 2009 7:39 PM
    Monday, April 6, 2009 9:52 PM
    Moderator