Re: [w3ctag/design-reviews] IndexedDB putAll (#536)

I find both, all-or-nothing, or partial updates having genuine use-cases, but personally would expect a set of keys with partial commits happening.

additional thoughts - 
At the risk of increasing the complexity of the putAll usage early on. I would prefer it to be parametrized.

parameters - 
allOrPart = All/Part-  the approach to take. 
returnKeys = Success/Failure/Both - the sets to return

"All" - In this approach while the data itself is not committed.
For "All", "Success" returns all keys updated successfully (which is not very useful for an "All" approach and maybe ignored). "Failure" returns the keys which failed to update for whatever reason. "Both" returns whatever keys were successful and whatever keys failed, to help mitigate.

"Part" - In this approach, any data which could be successfully updated, gets committed.
For "Part" - "Success" returns only all keys updated successfully, "Failure", only the failed keys, "Both" returns both the success and failed key sets.

Another point that I can think of is that the definition of "Success" itself may need to be clarified. 
Should everything that was "updated" irrelevant of an addition or update be labeled a "Success". OR Are only "updates" considered a success.  

And what is the definition of an "update"
Is updating data without any difference in the incoming and existing sets -` ("key_1", {title: "Quarry Memories", author: "Fred"}) ` updated the ObjectStore which previously had ` ("key_1", {title: "Quarry Memories", author: "Fred"})` an update ?
vs
 updating ` ("key_1", {title: "Quarry Memories", author: "Fred"}) `  to `("key_1", {title: "Quarry Memories original value", author: "Fred"})` in the ObjectStore


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/536#issuecomment-670534332