Re: [IndexedDB] IDBRequest.onerror for DataCloneError and DataError

On Sun, May 19, 2013 at 6:37 PM, Kyaw Tun <kyawtun@yathit.com> wrote:

> Sorry for reposting again for
> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0422.html Perhaps
> I am not well explain enough.
>
> In put and add method of object store and index, DataCloneError and
> DataError are immediately throw before executing IDBRequest. It seems good
> that exception are throw immediately, but in practical use case, these
> exception are in async workflow (inside transaction callback). Exception
> break the async workflow, (of course, it depending on usage design
> pattern).
>
> DataCloneError and DataError are preventable in most situation. But
> sometimes tricky. We even want database to handle these errors like
> database constraint. The logic will be much simpler if DataCloneError and
> DataError cause to invoke IDBRequest.onerror rather than exception.
>

I can see where this might be desirable if arbitrary data is being used for
values - for example, the key path yields an invalid key, or the value
contains a non-cloneable member.

>From an implementation perspective, both must occur synchronously. The
clone operation needs to determine the key and serialize the object at the
time the call is made, otherwise the object could change. (As an
implementation detail in Chrome at least, the data is thrown into another
process when the call is made so it needs to be serialized anyway.)

I seem to recall some discussion late last year about trying to make
serialization asynchronous, to avoid main thread jank when passing data to
Workers. The response was to make things transferable instead of
serializing them. I can imagine an API where e.g. you could pass in a Typed
Array and rather than being serialized synchronously it would have
ownership transferred instead, then be serialized asynchronously.... but
you'd still need to verify that the object was transferable up front so I'm
not sure you'd gain anything in the error case.