Re: [IndexedDB] Granting storage quotas
nikunj, i agree with what jeremy said. i think we need each storage API to be able to specify what kind of storage it needs (and i'm trying to add an optional flag for that to WebSQLDatabases, which is your option #1). in addition to that, i think we need an API that would allow an app to request persistent storage up front independent of the specific storage APIs the app will use (your option #3?), but it doesn't look like that is going anywhere. dumi On Thu, May 6, 2010 at 3:30 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, May 6, 2010 at 9:36 AM, Nikunj Mehta nik...@o-micron.com wrote: Dumi, I am not sure what the API expectations are for different levels of durability of storage APIs. Is it: 1. Options passed to individual APIs selecting durability level 2. Separate API calls for different durability level 3. Allocations occurring through markup requiring user actions which acts as ambient durability level for a site. I surely would like to avoid 1 and 2. I felt like the discussion (based on your proposal) was leaning towards 3. However, I can't read this email in that way. Thanks for clarifying for my sake. I don't think you've accurately characterized the situation. 1 vs. 2 has been bike-shedding so far. In other words, I don't think there have been any super compelling arguments for or against them, but I think 1 has had a bit more support. Either 1 or 2 is required in order for a single origin to have multiple levels of durability. For example, I have 14GB of email in my GMail account. I'd like to have a guarantee that I have at least the last 7 days of email + any drafts + emails in my outbox. I'd also like it to cache all the rest, but if my hard drive fills up, I'm happy for it to drop the extra. Another example: I have a photo sharing site. I upload a bunch of photos while offline that I'd like it to upload once I get back online. I also have several gigs of data cached to make the photo browsing experience better, but I'm fine with it being deleted. These types of scenarios become even more compelling when we're talking about mobile devices and net-books. I know it's been argued that these devices keep getting more storage, so we won't need to worry about it soon, but I'd argue that storage usage keeps increasing as well. 3 is a separate issue and is related to HOW we grant permissions. I think several of us at Google are in favor of something like this, but I haven't seen anyone else express interest so we're going to continue on without the new piece of markup for now, but if there was support for it, I think we'd be happy to go that route. J
Re: [IndexedDB] Granting storage quotas
ian, it seems to me that nobody objects to adding a isPersistent optional
parameter to openDatabase{Sync}() in the WebSQLDatabases spec (default =
false). can you please add it to the spec? if isPersistent = true and the UA
doesn't support persistent storage, then i believe openDatabase{Sync}()
should throw a SECURITY_ERR just like it does when the DB cannot be opened.
thanks,
dumi
On Thu, Apr 29, 2010 at 1:20 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/29/2010 1:08 PM, Tab Atkins Jr. wrote:
When you say per site do you mean per subdomain, or per domain? The
former is too permissive, the latter is too restrictive.
I believe he means per origin. At least that's what I took from our
discussion.
Cheers,
Shawn
Re: [IndexedDB] Granting storage quotas
shawn, did you have a chance to give this some thought? how would mozilla like to handle cases like the ones jeremy and robin mentioned? how would you like to manage quotas? thanks, dumi On Fri, Apr 23, 2010 at 11:08 AM, Shawn Wilsher sdwi...@mozilla.com wrote: On 4/23/2010 7:39 AM, Nikunj Mehta wrote: Could we create an additional optional parameter for an open request with the type of permanence required? Or is it not a good idea? I haven't talked to anyone at Mozilla that thinks that having permanent and non-permanent-but-possibly-long-lasting data to be a good idea. There does seem to be support for a session-only version of indexedDB. Cheers, Shawn
Re: [WebSQLDatabase] Adding a vacuum() call
shane, i was hoping you could clarify a few things about AUTO_VACUUM: However, the B-Tree balancing algorithm used by SQLite will attempt to merge pages with neighbors when there space utilization drops below certain thresholds. Minimum average fill for intkey leaves is 50%. For other pages I think it's 66%. according to http://www.sqlite.org/pragma.html#pragma_auto_vacuum: Auto-vacuum does not defragment the database nor repack individual database pages the way that the VACUUM command does. so the way i understand these statements is: 1. sqlite always attempts to merge mostly-empty pages. the (auto-)vacuum settings have no effect on that. 2. AUTO_VACUUM only moves pages around and deletes the empty ones. it does not try to repack individual pages. however, because of #1, page repacking happens anyway (to some extent), when AUTO_VACUUM is on. am i right? and one more question: Auto-vacuuming is only possible if the database stores some additional information that allows each database page to be traced backwards to its referer. Therefore, auto-vacuuming must be turned on before any tables are created. It is not possible to enable or disable auto-vacuum after a table has been created. what happens if we create a database without AUTO_VACUUM on, insert some data, save it to a file, then turn on AUTO_VACUUM and try to open that database again? will sqlite add the missing information? will AUTO_VACUUM be silently turned off for that database? will we get an error when we try to open/read from/write to that database? anything else that we need to be aware of in this case? thanks, dumi
Re: [WebSQLDatabase] Adding a vacuum() call
joao,
it looks like we mostly agree on this feature, so i was wondering if we
could formally agree on a spec. here's what i propose:
1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
implementations use SQLite, and in SQLite the command is called VACUUM. so
it seems to me that we might as well call the new function vacuum(). what do
you think?
2. spec: no need for an error callback.
interface Database {
// the methods and properties currently in the spec
void vacuum(in optional SQLVoidCallback successCallback);
};
3. what the call should do: the purpose of this call is to allow apps to
vacuum/compact/defragment/clean up their databases whenever they see fit. a
call to vacuum() could take a considerable amount of time (especially on
larger or highly fragmented databases); therefore, it is not recommended for
web apps to call this method during periods of high activity.
how to process a vacuum() call:
1. if the UA does not support this call (mobile browsers?), jump to step
3.
2. queue up a task to vacuum/compact/defragment/clean up the database.
3. if the task succeeds, and a success callback is provided, queue up a
task to invoke the success callback; in all other cases (the task failed, or
no success callback was provided), do nothing: proceed to the next task in
the queue.
does this seem acceptable? we (google engineers interested in this) feel
that UAs should either not implement the vacuum() call, or they should
respect it (rather than taking it as a hint). it is ok for UAs to keep track
of things like system idleness or databases closing to do more vacuuming
that the apps asked for, if they want to. however, we feel that a vacuum()
request by an app should not be postponed, simply because sometimes apps
know better than UAs when the best time to vacuum is (it might be nice to
give apps more information on how fragmented their databases are, but that's
a separate discussion).
thanks,
dumi
2010/3/9 Jeremy Orlow jor...@google.com
On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc d...@google.com wrote:
On Mon, Mar 8, 2010 at 3:39 AM, João Eiras jo...@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
Re: [WebSQLDatabase] Adding a vacuum() call
sounds good to me:
interface Database {
// the methods and properties currently in the spec
void vacuum(in optional SQLVoidCallback completionCallback);
};
... upon completion, queue up a task to invoke the completionCallback, if
one was provided.
dumi
On Thu, Mar 11, 2010 at 4:20 PM, Michael Nordman micha...@google.comwrote:
Instead of calling back on success only, maybe call back on completion
regardless of success or failure. This way the caller would know when the
potentially lengthy operation was done, regardless of the outcome.
2010/3/11 Dumitru Daniliuc d...@chromium.org
joao,
it looks like we mostly agree on this feature, so i was wondering if we
could formally agree on a spec. here's what i propose:
1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
implementations use SQLite, and in SQLite the command is called VACUUM. so
it seems to me that we might as well call the new function vacuum(). what do
you think?
2. spec: no need for an error callback.
interface Database {
// the methods and properties currently in the spec
void vacuum(in optional SQLVoidCallback successCallback);
};
3. what the call should do: the purpose of this call is to allow apps to
vacuum/compact/defragment/clean up their databases whenever they see fit. a
call to vacuum() could take a considerable amount of time (especially on
larger or highly fragmented databases); therefore, it is not recommended for
web apps to call this method during periods of high activity.
how to process a vacuum() call:
1. if the UA does not support this call (mobile browsers?), jump to
step 3.
2. queue up a task to vacuum/compact/defragment/clean up the database.
3. if the task succeeds, and a success callback is provided, queue up
a task to invoke the success callback; in all other cases (the task
failed,
or no success callback was provided), do nothing: proceed to the next task
in the queue.
does this seem acceptable? we (google engineers interested in this) feel
that UAs should either not implement the vacuum() call, or they should
respect it (rather than taking it as a hint). it is ok for UAs to keep track
of things like system idleness or databases closing to do more vacuuming
that the apps asked for, if they want to. however, we feel that a vacuum()
request by an app should not be postponed, simply because sometimes apps
know better than UAs when the best time to vacuum is (it might be nice to
give apps more information on how fragmented their databases are, but that's
a separate discussion).
thanks,
dumi
2010/3/9 Jeremy Orlow jor...@google.com
On Mon, Mar 8, 2010 at 8:47 PM, Dumitru Daniliuc d...@google.com wrote:
On Mon, Mar 8, 2010 at 3:39 AM, João Eiras jo...@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
Re: [WebSQLDatabase] Adding a vacuum() call
joao,
if i understand correctly, you basically want to have an automated system
implemented in the browser that decides when to vacuum databases (or at
least make sure it doesn't happen too often). and the vacuum() calls would
be just one of the parameters that the system takes into account. i think
having such a system is fine, but doesn't need to be spec'ed. at the same
time, i think it's worth having a spec'ed vacuum() call that gives the app
some guarantees. in particular, i would like the completionCallback to be a
signal that the database is in a good shape and ready for more work. so how
about this:
1. if the UA doesn't support the vacuum() call, go to step 3.
2. queue up a task to vacuum the database. if the UA decides that
vacuuming is not needed at this time, the vacuuming task scheduled in this
step could be a no-op.
3. when the vacuuming task completes, queue up a task to invoke the
completion callback, if one was specified.
i think this spec should allow you to treat the vacuum() call as a hint,
while also guaranteeing that:
1. the UA believes the database is in a good shape when the completion
callback is called.
2. the completion callback is called as soon as UA believes the DB is in a
good shape.
what do you think?
thanks,
dumi
On Thu, Mar 11, 2010 at 4:13 PM, João Eiras jo...@opera.com wrote:
On Fri, 12 Mar 2010 01:08:41 +0100, Dumitru Daniliuc d...@chromium.org
wrote:
joao,
it looks like we mostly agree on this feature, so i was wondering if we
could formally agree on a spec. here's what i propose:
1. name: vacuum. to the best of my knowledge, all current WebSQLDatabases
implementations use SQLite, and in SQLite the command is called VACUUM. so
it seems to me that we might as well call the new function vacuum(). what
do
you think?
I'm fine with it but...
2. spec: no need for an error callback.
interface Database {
// the methods and properties currently in the spec
void vacuum(in optional SQLVoidCallback successCallback);
};
3. what the call should do: the purpose of this call is to allow apps to
vacuum/compact/defragment/clean up their databases whenever they see fit.
a
call to vacuum() could take a considerable amount of time (especially on
larger or highly fragmented databases); therefore, it is not recommended
for
web apps to call this method during periods of high activity.
how to process a vacuum() call:
1. if the UA does not support this call (mobile browsers?), jump to step
3.
2. queue up a task to vacuum/compact/defragment/clean up the database.
3. if the task succeeds, and a success callback is provided, queue up a
task to invoke the success callback; in all other cases (the task
failed, or
no success callback was provided), do nothing: proceed to the next task
in
the queue.
does this seem acceptable? we (google engineers interested in this) feel
that UAs should either not implement the vacuum() call, or they should
respect it (rather than taking it as a hint). it is ok for UAs to keep
track
of things like system idleness or databases closing to do more vacuuming
that the apps asked for, if they want to. however, we feel that a vacuum()
request by an app should not be postponed, simply because sometimes apps
know better than UAs when the best time to vacuum is (it might be nice to
give apps more information on how fragmented their databases are, but
that's
a separate discussion).
I unfortunately don't agree with this last sentence :) Web pages do not
have a way to know the level of fragmentation, and the last thing user wants
is a web page calling vacuum() before each transaction, *just to be safe*,
because of potential fragmentation.
But the API is good I think.
thanks,
dumi
Re: [WebSQLDatabase] Adding a vacuum() call
On Thu, Mar 11, 2010 at 7:17 PM, João Eiras jo...@opera.com wrote: On Fri, 12 Mar 2010 04:07:21 +0100, Dumitru Daniliuc d...@chromium.org wrote: joao, if i understand correctly, you basically want to have an automated system implemented in the browser that decides when to vacuum databases (or at least make sure it doesn't happen too often). and the vacuum() calls would be just one of the parameters that the system takes into account. i think having such a system is fine, but doesn't need to be spec'ed. at the same time, i think it's worth having a spec'ed vacuum() call that gives the app some guarantees. in particular, i would like the completionCallback to be a signal that the database is in a good shape and ready for more work. so how about this: 1. if the UA doesn't support the vacuum() call, go to step 3. 2. queue up a task to vacuum the database. if the UA decides that vacuuming is not needed at this time, the vacuuming task scheduled in this step could be a no-op. 3. when the vacuuming task completes, queue up a task to invoke the completion callback, if one was specified. i think this spec should allow you to treat the vacuum() call as a hint, while also guaranteeing that: 1. the UA believes the database is in a good shape when the completion callback is called. 2. the completion callback is called as soon as UA believes the DB is in a good shape. what do you think? Looks better, and more flexible. thanks. is there anything else you'd like to change? i'm pushing for this so hard because i'd like to implement this feature, but i don't want to start before all interested parties agree on a spec. I wonder if sqlite has a way to query the number of pages in the freelist ? Probably something like 10% of pages in the freelist would be a good threshold to allow a vacuum. you can get the number of free pages with PRAGMA freelist_count ( http://www.sqlite.org/pragma.html). unfortunately, looking only at this number would result in a lot of false negatives. for example, in theory, you could have a DB with 1000 2KB pages, and each page could have only one useful byte written on it. so PRAGMA freelist_count would return 0, even though doing a vacuuming would shrink your DB from ~2MB to ~1KB. but i agree that it could be one of the parameters to take into account.
Re: [WebSQLDatabase] Adding a vacuum() call
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
[WebSQLDatabase] openDatabase() creation callback
Hi,
I know that not many people on this list care about the WebSQLDatabase spec
anymore (especially when it comes to changing it), but Chromium extension
developers do. So I was hoping somebody could explain the idea behind having
openDatabase() take a creationCallback. As I understand it, the callback is
supposed to be a place where the user initiates the DB (changes version,
creates tables, etc.). However, if we follow the spec, then this callback
becomes quite useless.
*Example 1:*
function creationCallback(db) {
db.transaction(...); // change version, create tables, etc.
}
var db = openDatabase(..., creationCallback);
db.transaction(tx1);
db.transaction(tx2);
According to the spec, if the database doesn't exist, we must queue a task
to run creationCallback (4.1) and return from openDatabase(). Then we queue
up tasks for the 2 transactions (4.3.2). So our queue ends up looking like
this:
1. invoke creationCallback
2. invoke the transaction callback for tx1
3. invoke the transaction callback for tx2
Now we invoke creationCallback, and find a transaction there, so we queue up
a task to invoke the transaction callback (4.3.2). Now our queue looks like
this:
1. invoke transaction callback for tx1
2. invoke transaction callback for tx2
3. invoke transaction callback for the transaction defined inside
creationCallback
As you can see, if we follow the spec, we end up running the transaction(s)
in creationCallback AFTER all other transactions in the code. So what's the
point of having a creationCallback?
*Example 2:*
function creationCallback(db) {
db.changeVersion(...); // change version to 1.0
}
var db1 = openDatabase(db, 1.0, , 1, creationCallback);
var db2 = openDatabase(db, 1.0, , 1);
According to the spec, if db doesn't exist, then the first openDatabase()
will set the version to (empty string) and queue up the creationCallback.
Now before we have a chance to invoke the creationCallback, the second call
to openDatabase() happens, and fails with a INVALID_STATE_ERR (as requested
by the spec), because a database with that name exists, it's version is ,
and we expect the version to be 1.0. So again, the creationCallback which
was supposed to change the version comes in after the rest of the code has
already failed.
So it seems to me that if we follow the spec, then the creationCallback
becomes nothing more than a flag that tells us whether or not the DB existed
(and a pretty poor implementation of such a flag too, since it's set only
after we're done executing the rest of the code). Is this really the
intended purpose of this callback? If not, assuming the purpose of this
callback was to initialize the database before running any transactions on
it, I propose the following changes to the spec:
1. If the database doesn't exist and a creationCallback is specified, *
invoke* the creation callback at the very end of openDatabase(). (This would
take care of the problem described in example 1.)
2. If the database doesn't exist, always set its version to the given one.
If a creation callback was specified, invoke it. If the creation callback
fails or raises an exception, reset the database version to . (This would
take care of the problem in example 2. And in case creationCallback fails,
we will reset the DB version to before any other transaction gets a
chance to run.)
Thanks,
dumi
[WebSQLDatabase] Minor change to spec?
In section 4.3.2, point 6, the In case of error... paragraph says: 2. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. I'm proposing the following change (the wording could be different, of course): 2. If the error callback returns false *and the transaction is not in an unrecoverable state*, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, if the error callback did not return false, or there was no error callback, *or the transaction is an unrecoverable state*, jump to the last step in the overall steps. This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: If certain kinds of errors occur on a statement within a multi-statement transaction (errors including SQLITE_FULLhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_IOERR http://www.sqlite.org/c3ref/c_abort.html, SQLITE_NOMEMhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_BUSY http://www.sqlite.org/c3ref/c_abort.html, and SQLITE_INTERRUPThttp://www.sqlite.org/c3ref/c_abort.html) then the transaction might be rolled back automatically. If such an error occurs, we cannot move on to the next statement as currently requested by the spec. Thanks, Dumi
Re: [WebSQLDatabase] Minor change to spec?
Thanks for clarifying this, Ian. Dumi On Mon, Feb 1, 2010 at 4:53 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 1 Feb 2010, Dumitru Daniliuc wrote: In section 4.3.2, point 6, the In case of error... paragraph says: 2. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. I'm proposing the following change (the wording could be different, of course): 2. If the error callback returns false *and the transaction is not in an unrecoverable state*, then move on to the next statement, if any, or onto the next overall step otherwise. 3. Otherwise, if the error callback did not return false, or there was no error callback, *or the transaction is an unrecoverable state*, jump to the last step in the overall steps. This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: If certain kinds of errors occur on a statement within a multi-statement transaction (errors including SQLITE_FULLhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_IOERR http://www.sqlite.org/c3ref/c_abort.html, SQLITE_NOMEMhttp://www.sqlite.org/c3ref/c_abort.html, SQLITE_BUSY http://www.sqlite.org/c3ref/c_abort.html, and SQLITE_INTERRUPThttp://www.sqlite.org/c3ref/c_abort.html) then the transaction might be rolled back automatically. If such an error occurs, we cannot move on to the next statement as currently requested by the spec. These fall under the general User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations. rule, under which you can basically do whatever you need to do to handle unexpected errors. If I edit the spec again, I'll make this more clear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [WebSimpleDatabase] New spec, editor's draft available
http://dev.w3.org/2006/webapi/WebSimpleDatabase/http://dev.w3.org/2006/webapi/DataCache/ FYI: you should probably copy-paste the link that nikunj sent in his email. clicking on it takes you to http://dev.w3.org/2006/webapi/DataCache/. dumi
[web databases] SQLStatementErrorCallback
Hi, When talking about statement error callbacks (point #6, section 4.3.2), the spec says: 1. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 2. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. What should happen if the callback doesn't return anything (undefined)? Should we jump to the transaction error callback? Can/should we clarify this in the spec too? Thanks, Dumi
Re: [webdatabase] Transaction Locks
I can't speak for the spec authors, but I can tell you what WebKit does at the moment. We acquire a lock before we run the transaction callback, but just like you, we do not have a timeout that invokes the error callback. So it seems to me like overall our implementations should behave similarly (we wait for the lock before running the transaction callback, you wait for it before running the first statement). 1. Is it OK to start a transaction callback without getting a lock first? I don't see why not, as long as the transaction produces the correct result. 2. Do we need to have a timeout on acquiring locks (or anything else, for that matter) when opening transactions? I don't think so. As a user, I'd rather have a sometimes slow web page than a sometimes failing one. dumi On Mon, Aug 31, 2009 at 4:37 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
