Re: [IndexedDB] Lots of small nits and clarifying questions
On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta nik...@o-micron.com wrote: Thanks for your patience. Most questions below don't seem to need new spec text. On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: I'm sorry that I let so much IndexedDB feedback get backlogged. In the future, I'll try to trickle things out slower. * * *Indexes:* 1) Creation of indexes really needs to be made more clear. Did you mean the algorithm for this process or the API documentation? For example, does creation of the index block everything until it's complete or does the database get created in the background? If the index is created using the synchronous call, then the calling worker will block until the index is created. If the async API is used, the rest of the database can continue to work and the worker should be able to continue to other calls without waiting for the index creation to get over. What if I have 1gb of my mail stored in IndexedDB and then a database migration adds an index? Depends on your choice of workers and sync/async API. Is my app completely unusable during that time? It doesn't have to be in a well-designed app. What if the browser is exited half way through building (you can't just delete it)? Regardless of whether the sync or the async API, if you choose to perform DDL (not just index creation, but also database creation) in a transaction, then it could be done atomically. What happens if you query the database while it's building in the background-building case (should it emulate it via entity-store-scans)? The index doesn't exist until it is created. If you use an index before it exists (even if it is in the process of being created), then the outcome depends on whether the index is created in a transaction. If yes, the call will fail because the index will not exist. If no, then the call may use partial index results. These are all very important questions whose answers should be standardized. This feels like good non-normative text to me. All of this seems fine for v1. 2) Why are Indexes in some database-global namespace rather than some entity-store-global namespace? This approach is fine by me. I know in SQL, most people use the table name as a prefix for their index names to make sure they're unique. Why inherit such silliness into IndexedDB? Why not connect every index to a particular entity-store? Indexes in IndexDB are already dependent on an entity store. Ok, then I'd suggest we move the create/open/delete index methods to the IDBObjectStoreSync/IDBObjectStoreRequest interfaces to reflect this. 6) The specific ordering of elements should probably be specced including a mix of types. Can you propose spec text for this? What do you think about the text in http://www.w3.org/TR/IndexedDB/#key-construct? If we're only adding long long for v1, then I think language similar to what's there now is probably OK. But now that I think about it, I'm a bit concerned that we might be backing ourselves into a corner for the future. I also noticed that the sort order of JavaScript seems to order it numbers, strings, and then nulls (not strings, numbers, nulls). I wonder if there is some other spec on sort order we can cite rather than rolling our own. *Key ranges / cursors:* 1) Is an open or closed key range the default? Not sure what you mean by default here? The parameters are optional. If you don't specify them, what should they be? 2) What happens when data mutates while you're iterating via a cursor? This is covered by http://www.w3.org/TR/IndexedDB/#dfn-mode That applies to two separate transactions. As far as I can tell, it should be possible to have a cursor open and then delete an element that the cursor is currently traversing all within the same transaction. Am I missing something? 3) In the spec, get and getObject seem to assume that only one element can be returned...but that's only true if unique is true. What do you do if there are multiple? ObjectStore doesn't allow storage of multiple values with a given key. See http://www.w3.org/TR/IndexedDB/#object-store-concept Multiples only make sense if you are retrieving from an Index. The following spec text could be added to 3.2.5 and 3.2.6 to return the first value in the sorted order of their keys. This text should work. 3.2.5 3. Let /value/ be the value of the record first in the sorted order of their keys corresponding to the key /key/ in /index/ 3.2.6 3. Return the value for the record first in the sorted order of their keys corresponding to the key /key/ in /index/ 4) Why can the cursor only travel in one direction? Many things are possible. This is a scope limitation. You can open multiple cursors each going in different directions. I was just trying to understand why. I agree there's no super compelling use case. 5) What if you modify a value that then implicitly (via the
[IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)
On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta nik...@o-micron.com wrote: On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: 2) In the spec, dynamic transactions and the difference between static and dynamic are not very well explained. Can you propose spec text? In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first paragraph, adding a sentence would probably be good enough. If the scope is dynamic, the transaction may use any object stores or indexes in the database, but if another transaction touches any of the resources in a manner that could not be serialized by the implementation, a RECOVERABLE_ERR exception will be thrown on commit. maybe? By the way, are there strong use cases for Dynamic transactions? The more that I think about them, the more out of place they seem. Background: Dynamic and static are the two types of transactions in the IndexedDB spec. Static declare what resources they want access to before they begin, which means that they can be implemented via objectStore level locks. Dynamic decide at commit time whether the transaction was serializable. This leaves implementations with two options: 1) Treat Dynamic transactions as lock everything. 2) Implement MVCC so that dynamic transactions can operate on a consistent view of data. (At times, we'll know a transaction is doomed long before commit, but we'll need to let it keep running since only .commit() can raise the proper error.) Am I missing something here? If we really expect UAs to implement MVCC (or something else along those lines), I would expect other more advanced transaction concepts to be exposed. If we expect most v1 implementations to just use objectStore locks and thus use option 1, then is there any reason to include Dynamic transactions? J
Re: [IndexedDB] Explaining Asynchronous event-style interface
On Sat, Mar 13, 2010 at 9:43 AM, Nikunj Mehta nik...@o-micron.com wrote: (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 IndexedDatabaseRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-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 IDBDatabaseRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBDatabaseRequestobject, 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 IDBDatabaseRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBDatabaseRequestobjects 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 IDBIndexRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBIndexRequest and IDBObjectStoreRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-IDBObjectStoreRequest object as required. Once these objects are created multiple operations can be performed in parallel. Same goes for IDBCursorRequesthttp://dev.w3.org/2006/webapi/WebSimpleDB/#idl-def-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 This is a very good summary. Thanks Nikunj. It'd be great if others (especially the proponents of the event based model) could weigh in on whether they like this and/or what changes they might make. From an implementors perspective: this is actually easier to implement what's currently specced rather than a callback based model. If I was trying to write a library on top of IndexedDB that exposes a callback and/or promise based API, I would rather a callback based, but I think I could get my job done with this. For each request object, I'd probably just create an array and attach it to the object and use that as a queue of items to be done. If I wanted to optimize for multiple operations in flight at any time, I could even maintain pools of connections, object stores, indexes, etc that automatically grow when too many items get queued up at once. I'm not saying it'd be easy, but it's possible. If I were trying to write code on the bare API, personally I would prefer a callback based model, but perhaps I'm just odd. On the other hand, I think we've made it pretty clear that ease of use is a much lower priority compared to making an API with a small surface area that is powerful and is able to be wrapped by user friendly libraries. So, in summary, I've actually been arguing against what will make my life easiest. But maybe we should just leave the async API as is and move on? I hope others will chime in on this though. Especially people who were originally in favor of an event based model. J
