(starting a new thread to focus discussion on identifying shortcomings
of currently specced API)
As specced, it is possible to have multiple concurrent requests at
various API entry points, except for the IndexedDatabaseRequest
interface. In this particular case, you can only have one request to
open a database in a Window object. Given that this is setup kind of
work, it does not appear that this limitation amounts to much. If
multiple connections to a single DB are required, or if different DBs
have to be opened, that would have to be done sequentially, i.e.,
start a new request only after the previous one completed.
Once you have an IDBDatabaseRequest object, it is possible to make one
request at a time to open a cursor or create a transaction. It is
possible to do this concurrently with opening another database. If
multiple concurrent requests are to be made to create and/or open
object stores or indexes, different connections in the form of
IDBDatabaseRequest objects will be needed. Again, this appears largely
an initial set up kind of thing. Besides, given that it is possible to
check whether a request is in progress, developers can avoid getting
into trouble.
One can create as many IDBIndexRequest and IDBObjectStoreRequest
object as required. Once these objects are created multiple operations
can be performed in parallel.
Same goes for IDBCursorRequest objects and performing operations on
several different such objects.
I am trying to explain this to those who haven't had a chance to
review the spec but might be able to weigh in on our discussion
Nikunj
- [IndexedDB] Explaining Asynchronous event-style interface Nikunj Mehta
-