I haven't been following the discussion with IndexedDB closely, but I
think the general ID of an indexed name/value store is a great idea,
and would be Good for the web.
However, I do agree with Jeremy that the current shape of the API is
too confusing. Maybe I can be useful as a new set of eyes.
Looking at just this snip:
function findFred(db) {
db.request.onsuccess = function() {
var index = db.request.result;
index.request.onsuccess = function() {
var matching = index.request.result;
if (matching)
report(matching.isbn, matching.name, matching.author);
else
report(null);
}
index.get('fred');
}
db.openIndex('BookAuthor');
}
This example is hard to read where the callback is setup before the
call like this. Without making any API changes, I think you could
improve things:
db.openIndex('BookAuthor');
db.request.onsuccess = function() {
...
};
You just have to make sure that the API guarantees that
onsuccess/onfailure will always be called in a separate event, which
is important anyway for consistency.
I think it's counter-intuitive to have a single 'request' object per
database. Even though it might be technically true that in
single-threaded JavaScript that is the reality. A request describes
something that there are many of, that doesn't get reused. Reusing the
single onsuccess event also seems like something that is likely to
cause bugs (people forgetting to reset it correctly, an old callback
gets fired). Finally, developers might be used to XHR, where there are
of course multiple requests.
So I think one improvement could be create one request for each logical request:
function findFred(db) {
var req1 = db.openIndex('BookAuthor');
req.onsuccess = function() {
var index = req1.result;
var req2 = index.get('fred');
req2.onsuccess = function() {
...
}
}
}
Like I said, I've only thought about this for a moment. I know how
hard API design can be, and these are my drive-by first-blush
comments. But on the other hand, sometimes drive-by, first-blush
comments are useful for figuring out APIs.
HTH,
- a