Just making sure I'm understanding this correctly....

# store

[spierce7]

Just making sure I'm understanding this correctly. Lets say I have 2 Requests that return List<Item> .

Lets say I make Request A, and it returns `Item`s with the ids: [1, 2, 3].

Then sometime later I make Request B, and it returns `Item`s with the ids [3, 4, 5], and lets say that the ID 3 has values that were updated by the server, from some other operation unknown to my mobile app.

If my mobile app gets the cached Request A again, it gets the updated item with ID 3 , right? Obviously Store has no idea that 1 and 2 could be out of date though.

[Matthew Ramotar]

What you’re looking for is possible, though it’s not supported out of the box. If you’re using a standard Store and requests A and B use the same Key, then the second value [3, 4, 5] will overwrite the first value [1, 2, 3].

Insertion strategies will be added in Store6: https://github.com/MobileNativeFoundation/Store/pull/550

And Store6 snapshots will be available soon: https://github.com/MobileNativeFoundation/Store/pull/591

[spierce7]

@Matthew Ramotar So items are cached based off the request Key entirely, not based off the item ID?

[spierce7]

so I'll end up with 2 different versions of Item with ID 3 cached / stored?

[Matthew Ramotar]

Out of the box, the response value would be cached as a list. If you’re using MultiCache and Store5, the list will be overwritten, but the items would be cached individually, so you’d have items 1 and 2 based on the first response and items 3-5 based on the second response.

[Matthew Ramotar]

So out of the box, you wouldn’t end up with different versions of item 3

[spierce7]

oh, perfect

[spierce7]

so request B would overwrite the cache for Item #3

[spierce7]

that's what I would expect