[whatwg] Asynchronous database API feedback

[Benjamin West]

On Dec 9, 2007 1:29 AM, Aaron Boodman <aa at google.com> wrote:
> I like the new Database API design a lot, but I wish there was an
> option for synchronous DB access.
>
> I did some quick tests and I can insert 1000 rows, totaling 3KB+ of
> data into SQLite in less than a tenth of a second on Windows (I don't
> have a mac here, but I recall Windows was slower when we last tested).
> Reading takes a similar amount of time. It is definitely possible to
> construct queries that will take a long time to execute, but I feel
> that isn't the majority use case. Simple applications deal with a
> relatively small amount of data at a time, and disk latency isn't an
> issue for them. As an example, I use Gearpad
> (http://aaronboodman.com/gearpad) on a daily basis and it interacts
> with the database synchronously on the UI thread. The app feels very
> responsive to me. An asynchronous database API would just making
> writing that application harder with no real benefit.
>
> I think there should at least be the option of a synchronous API for
> the simple use cases.
>
[snip]
> Thoughts?
>
> - a


I suspect that this closely matches what actually happens in practice for most
developers on the server side.  When application developers prepare data for
the view on the server, I believe it most often happens synchronously.
Doesn't most database access in PHP and other popular environments happen
synchronously?

Regardles, for all web applications, unless the application has been carefully
tuned to take advantage of HTTP streaming, the delivery of the UI is
completely blocked until all db access has finished.

It's unclear how this might affect developers using the offline API.

Ben West