Re: [WebSQLDatabase] Adding a vacuum() call

On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc <dumi@google.com> wrote:

>
>
> On Mon, Mar 8, 2010 at 3:39 AM, João Eiras <joaoe@opera.com> wrote:
>
>>
>>  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.
>>>
>>>
>> True, but this is a kind of operation that could very well just run on the
>> background, with a single optional callback when it's done (the webpage
>> can't do anything if an error is detected anyway).
>
>
> ok, so let's drop the errorCallback: vacuum([optional] successCallback);
>
>
>> The user agent would need to queue any subsequent transactions if a vacuum
>> is running. I would consider it as an hint, and after all webpages that own
>> references to the underlying data files are closed, would do a vacuum. So,
>> if you have many tabs on gmail, and that a single gmail instance tries to do
>> multiple vacuums, it would equiv to one single vacuum operation.
>
>
> what do we do if some databases are opened for the entire life of the
> browser? for example, i open my browser which has myfavoriteapp.com set as
> its homepage. myfavoriteapp.com immediately opens a DB, and i only close
> that app when i close the browser. when would the browser vacuum
> myfavoriteapp's DBs in this case?
>
> i think it's ok for the UA to vacuum some DBs automatically when it thinks
> it's a good time to do so; however, if a platform supports the vacuum/defrag
> call (i.e. if it doesn't treat it is a no-op), then i think a vacuum call
> coming from the app should be immediately scheduled (yes, the subsequent
> transactions would have to wait for the vacuuming to finish running). in
> some cases, the apps know better than the UA when to vacuum their DBs.
>
> by the way, we should probably agree on a name for this call. which one do
> you prefer? vacuum, defragment, defrag, something else? i don't have a
> strong opinion.
>

I think vacuum is fine since the spec is already tied to the SQLite SQL
dialect.

collectGarbage() is another possibility

Go with whatever you think is most clear and accurate though.

J