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 <jor...@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
