Re: [IndexedDB] Lots of small nits and clarifying questions

On Feb 28, 2010, at 3:24 PM, Jeremy Orlow wrote:

> Another nit: as far as I can tell, all of the common parts of the  
> interfaces are named Foo, the synchronous API portion is FooSync,  
> and the async API portion is FooRequest.  This is true except for  
> IndexedDatabase where the sync version is simply IndexedDatabase and  
> the async version is IndexedDatabaseRequest.  Can we please change  
> IndexedDatabase to IndexedDatabaseSync for consistency, even though  
> there is no common shared base class?

I have no problems with renaming. However, before we go too much in to  
renaming, it is important to finalize the async API style.

>
> J
>
> P.S. Would it be useful to accompany requests like this with a patch  
> against Overview.html?

That certainly helps.

>
> On Thu, Feb 18, 2010 at 5:08 PM, Jeremy Orlow <jorlow@google.com>  
> 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.  For  
> example, does creation of the index block everything until it's  
> complete or does the database get created in the background?  What  
> if I have 1gb of my mail stored in IndexedDB and then a database  
> migration adds an index?  Is my app completely unusable during that  
> time?  What if the browser is exited half way through building (you  
> can't just delete it)?  What happens if you query the database while  
> it's building in the background-building case (should it emulate it  
> via entity-store-scans)?  These are all very important questions  
> whose answers should be standardized.
>
> 2) Why are Indexes in some database-global namespace rather than  
> some entity-store-global namespace?  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?
>
> 3) What happens when unique constraints are violated?
>
> 4) I don't remember anything explicitly stating that when a value  
> changes that an index has a keypath referring to, that index should  
> be updated.
>
> 5) It definitely would be nice to be able to index more than just  
> longs and strings.
>
> 6) The specific ordering of elements should probably be specced  
> including a mix of types.
>
>
> Key ranges / cursors:
>
> 1) Is an open or closed key range the default?
>
> 2) What happens when data mutates while you're iterating via a cursor?
>
> 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?
>
> 4) Why can the cursor only travel in one direction?
>
> 5) What if you modify a value that then implicitly (via the key- 
> path) changes the index that your cursor is currently iterating over?
>
>
> Transactions:
>
> 1) We feel strongly that nested transactions should be allowed.   
> Closed nested transactions should be simple to implement and will  
> make it much easier for multiple layers of abstraction to use  
> IndexedDB without knowledge of each other.
>
> 2) In the spec, dynamic transactions and the difference between  
> static and dynamic are not very well explained.
>
> 3) I'm not sure that I like how the spec talks about commits being  
> durable but then later says "Applications must not assume that  
> committing the transaction produces an instantaneously durable  
> result. The user agent may delay flushing data to durable storage  
> until an appropriate time."  It seems like the language should be  
> made more consistient.  Also, it seems like there should be some way  
> to ensure it is durable on disk for when it's absolutely necessary.   
> (But maybe with a note that UAs are free to rate limit this.)
>
>
> Misc:
>
> 1) Structured clone is going to change over time.  And,  
> realistically, UAs won't support every type right away anyway.  What  
> do we do when a value is inserted that we do not support?
>
> 2) It seems that you can only be connected to one database at a  
> time?  If so, why?
>
> 3) Do we have enough distinct error codes?  For example, there are  
> multiple ways to get a NON_TRANSIENT_ERR when creating a  
> transaction.  Error strings can help with debugging, but they can  
> differ between UAs.  It seems as though all errors should be  
> diagnosable via the error codes.
>
> 4) In 3.3.2, openCursor takes in an optional IDBKeyRange and then an  
> optional direction.  But what if you don't want a range but you do  
> want a particular direction?  Are implementations expected to handle  
> this by looking at whether the first parameter is a IDBKeyRange or  
> not?  Same goes for IDBIndexSync.
>
> 5) Similarly, put takes 2 optionals.  Depending on the object store  
> it may or may not make sense for there to be a key param.  I guess  
> the javascript bindings will need to have knowledge of whether a key  
> is expected and/or disallow boolean keys?  It'd probably be better  
> to avoid this from a bindings point of view.
>
> 3.2.2.4 - why would you skip the next step?
> 3.2.2.6 - should be preform one or the other, right?
> 3.2.2.6.1 - should be "if it has a key generator" right?
>
> 3.3.2 - if createObjectStore converts a null name to the empty  
> string, why woudln't openObjectStore, create/open index, and  
> removeObjectStore/removeIndex?
>
>
> Thanks,
> Jeremy
>