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

Thanks for the feedback!

I guess the main difficulty here with the functionality that you're mentioning is that it conflicts with the existing patterns of the IndexedDB API. Currently all calls to get or modify data in the database follows an asynchronous pattern where the result of the API call is an IDBRequest object, and then the developer listens to a 'success' or 'error' event on that request object.

We don't have any API calls that can 'partially succeed', they all either succeed totally or fail totally. All requests are associated with a transaction, which again either totally atomically commits, or fails & is aborted (and all changes are not in the database).

Regarding updating as changing vs not changing, this also isn't an existing feature of the database. `putAll` is trying to model a bulk-inserting of `put`, so at least initially we want to model what `put` does. The one restriction we DO provide is `put` vs `add`, where `add` will error if a record already exists at the given key. It wouldn't be too hard for us to also create an `addAll` as well with our current implementation, not sure about others.

The feature knowing if a record has been 'changed' or not might be valuable, but we haven't received any feedback that people want this. We only have feedback that people want a putAll.

To keep things consistent with the existing API patterns, and to keep this change simple, I think we want to have putAll* be all-or-nothing, and have no extra options. I think we should probably return the array of keys that were committed - this is useful for people who have auto-increment on.

If you have a use cases for the behaviors above, definitely let us know. The only one that might be 'faster' if the API supported it would probably be the constraint for telling the user if the value was updated or not. Allowing some puts to fail is already supported by just using the `put` API as it already exists.

-- 
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-670657601