[whatwg] Asynchronous database API feedback

Aaron Boodman aa at google.com
Tue Dec 11 11:40:01 PST 2007


Dang, tab does not work in text areas. To finish my example...

var messages = incoming_data;

db.transaction(function(tx) {
  processNextMessage(tx);
});

function processNextMessage(tx) {
  var next = messages.shift();
  if (!next) return; // we're done

  tx.executeSql("insert into messages (id, subject, body) values (?, ?, ?)",
                       [next.id, next.subject, next.body], function(rs) {
    tx.executeSql("select 1 from threads where id = ?", [next.threadid],
                         function(rs) {
      if (!rs.rows.length) {
        // Create the thread table if necessary
        tx.executeSql("insert into threads (threadid) values (?)",
[next.threadid], function() {
          addMessageToThread(tx, message);
        });
      } else {
        addMessageToThread(tx, message);
      }
    });
  });
}

function addMessageToThread(tx, message) {
  tx.executeSql("insert into thread_messages (threadid, messageid)
values (?, ?)",
                       [message.threadid, message.id], processNextMessage);
}


// TODO(aa): handle contacts..

Anyway, this is a pretty simplified example, but I hope it shows how
hairy this can become. There are tools (the Deferred pattern) to help,
but it can't take away the underlying pain.

I thought it would be useful if the spec had a simple synchronous API
for cases where the developer expects operations to happen quickly
and/or doesn't care if they timeout ocassionally (because, for
example, the application will retry automatically later).

It's clear that most people here feel passionately that this is the
wrong thing to do. Perhaps it's best that we table this until
something like workerpools are in the spec.

- a



More information about the whatwg mailing list