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

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?

J

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

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
>