duplicate items in store when a new item's id is returned through Location header

[ben hockey]

• i add a new item to the store, it is automatically assigned an arbitrary id
• i save the store, the id assigned by the server is returned in the Location header
• an item with the new id is added to the store
• BUG: an item with the original arbitrary id is still in the store

with a grid attached to the store, the only item i see in the grid is the one with the arbitrary id - even after updating.

[ben hockey]

a dump of the appropriate records in the store:

{
  "/service/calendar/414af6155494a3bc77422ccc":
    {
      "name":"newItem",
      "id":"414af6155494a3bc77422ccc",
      "__clientId":"/service/calendar/414af6155494a3bc77422ccc",
      "__id":"/service/calendar/4855940"
    },
  "/service/calendar/4855940":
    {
      "name":"newItem",
      "id":"414af6155494a3bc77422ccc",
      "__clientId":"/service/calendar/414af6155494a3bc77422ccc",
      "__id":"/service/calendar/4855940"
    }
}

[Kris Zyp]

Are you sure those are duplicate items? Does store._indexservice/calendar/414af6155494a3bc77422ccc? != store._indexservice/calendar/4855940?? I believe those are actually the same object, just registered in the store for both the client and server ids (so they are accessible by both). I believe there is a bug here (and I will fix it) that the "id" property is not updated, but this will not have any affect on the items identity as provided through the getIdentity method; it is essential that getIdentity continue to return the client assigned id, even after getting a server id, otherwise the grid will break (it can't handle mutating identities).

[Kris Zyp]

(In [15269]) fixes #7673

[Kris Zyp]

(In [15296]) fixes #7673 by properly updating data based on response from PUT, POSTs. Fixes setting non-truthy values with setValue Fixes adding and deleting an item in one transaction