Re: [WebSQLDatabase] Adding a vacuum() call

You are of course correct that every database has administrative
commands like this; I probably overreacted in my wording, and I
apologize for that.

However, this is exactly the sort of request that makes people unhappy
with this spec. While other implementations have SQL DDL for doing
things like this, they don't typically expose a single-purpose
function, and so you'd be trying to cram other implementations
similar-but-not-identical functionality into this name.

What do we do? I think there is general consensus that you can't hope
to standardize on a SQL dialect as part of this spec. That seems to
leave you with three options: expose only a limited set of
functionality, expose a generic DBC API and accept that you will write
implementation-specific code using the generic APIs (although it would
be possible to write more generic APIs on top of that), or accept that
this is a SQLite-specific spec and call it that accordingly, to keep
from confusing people.

You all are probably correct that, especially in SQLite's case, you'll
need application-level access to the advanced features (and I say this
not because SQLite is somehow inferior but because AFAIK it doesn't
have background threads and the self-tuning more complex DBs tend to
have), so option #1 probably won't make anyone happy. So, I suggest
either you do #2 or #3. Don't just try to gradually had specific hooks
onto #1 and pretend this API is something it's not.

-- Dirk

On Fri, Mar 12, 2010 at 7:52 PM, Shane Harrelson <shane@sqlite.org> wrote:
> This is not an issue unique to SQLite.
>
> MySQL has several options for this, including  "OPTIMIZE TABLE foo".
> SQL Server has a SHRINK database option among others.
> Oracle has several options including "ALTER TABLE foo SHRINK SPACE".
>
> I think regardless of the underlying storage engine chosen, there will be
> extreme situations which stress any kind of automatic space and performance
> management algorithms and you'll find users asking for just such interfaces
> -- be it called vacuum(), optimize(), defragment(), shrink(), etc.
>
> -Shane
>
>
> On Fri, Mar 12, 2010 at 4:31 PM, Dirk Pranke <dpranke@chromium.org> wrote:
>>
>> I admit to not being super familiar with the spec as it currently
>> stands, but I find the idea
>> that we would add something like this fairly unappealing. I'm not
>> familiar with any other
>> database API that asks the application programmer to some sort of GC
>> as part of the
>> application. I almost feel like if you're going to add this, you
>> should drop any pretense of
>> calling this a generic SQL interface, and just call it the "WebSQLLite
>> spec".
>>
>> -- Dirk
>>
>> 2010/3/9 Jeremy Orlow <jorlow@google.com>:
>> > 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
>>
>
>

Received on Saturday, 13 March 2010 20:37:40 UTC