[WebSQLDatabase] Adding a vacuum() call

(reposting from the right email account)

hi joao,

thanks for your comments!


> I would argue about having something a bit more generic for naming like
> "defragment()".
>

that's totally fine with me.


> I don't see how the callbacks are useful though. Vacuum works
> transparently, its effects are not visible, and what should the page do in
> case of error ?
>

i was thinking of something like:

db.defragment(errorCallback, successCallback);
showAPrettyImageAndAskTheUserToWait();

function errorCallback(error) {}
function successCallback() {
  getRidOfThePrettyImageAndRestartTheApp();
}

just like you, i'm not sure if the error callback is useful at all, but i
thought i'd add it to make the defragment() call look more like a
transaction. maybe we don't need it.


> Given that an operation like vacuum would be disk IO intensive, would it be
> good to give the webpage control over a feature that can have significant
> performance concerns ?
>

first, i think it's better to give big, always-on apps access to a
potentially expensive clean-up call, than not give them any way at all to
defragment their databases. second, the app which called defragment() is the
only one that should notice the performance overhead (in practice, other web
apps might notice it too because of slower IO, but this is no different from
having an external, non-web app doing some intensive IO work and slowing
down all web apps). and third, most apps will probably never need to use
this call; it is mostly intended for apps with big databases that are always
open on a user's PC. those apps would usually know when they can call
defragment() without slowing down the user (for example, they could do it
when the app is idle).


> While computers benefit from good file IO performance, that's not quite
> true in many mobile devices. So, the API would be more like an hint ? How
> can the webpage know the level of fragmentation of the data file ?
>

on mobile devices i'm imagining the quotas and DBs are pretty small, in
which case defragmenting databases probably wouldn't save much space anyway.
so maybe those platforms should decide that they never need to do any kind
of maintenance on their DBs and make defragment() a no-op?

i don't think a webapp can figure out the level of fragmentation (maybe we
need an API to expose some quota/DB size information to the webapp?).
however, it could use other criteria to decide when to call defragment():
once every couple of weeks, when the system is idle, etc.


> Sqlite supports incremental vacuum http://www.sqlite.org/pragma.html so
> this kind of feature should be left for sqlite to handle for itself.
>

in addition to what jeremy said, having auto-vacuum on is going to add some
performance overhead to every transaction. this is not acceptable to some
apps.

thanks,
dumi