Re: [IndexedDB] Need a method to remove a database
On Wed, Aug 4, 2010 at 7:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher sdwi...@mozilla.com wrote: Hey all, Some of the feedback I've been seeing on the web is that there is no way to remove a database. Examples seem to be web page wants to allow the user to remove the data they stored. A site can almost accomplish this now by removing all object stores, but we still end up storing some meta data (version number). Does this seem like a legit request to everyone? Sounds legit to me. Feel somewhat embarrassed that I've missed this so far :) Agreed. What should the semantics be for open database connections? We could do something like setVersion, but I'd just as soon nuke any existing connection (i.e. make all future operations fail). This seems reasonable since the reasons we didn't do this for setVersion (data loss) don't really seem to apply here. Actually, there could dataloss apply here. Consider a page which creates a temporary database, fills it with data, and then slowly sends it to the server. Once all data has been sent to the server the database is removed. If you have two instances of that page open, one could remove the database while the other is still writing to it. Though this seems like a pretty scary setup anyway since if the user closes the second page midway through, the first one will succeed in deleting the database no matter what. Well, presumably the site won't delete a database programmatically if it still has important information in it. I mean, the same scenario you just explained could happen with .clear() or .removeObjectStore() as well. J
Re: [IndexedDB] Implicit transactions
On Wed, Aug 4, 2010 at 7:47 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 8/4/2010 10:53 AM, Jeremy Orlow wrote:
Whoatransaction() is synchronous?!? Ok, so I guess the entire premise
of my question was super confused. :-)
It is certainly spec'd that way [1]. The locks do not get acquired until
the first actual bit of work is done though.
I fully understand how the trick works. I just didn't comprehend the fact
that the Mozilla proposal (what's now in the spec) was removing any way to
get into an IDBTransactionEvent handler besides doing an initial data
access. I wouldn't have agreed to the proposal had I realized this.
Lets say I had the following bit of initialization code in my program:
var myDB = ...
var myObjectStore = myDB.objectStore(someObjectStore);
var myIndex = myObjectStore.index(someIndex);
var anotherObjectStore = myDB.objectStore(anotherObjectStore);
And then I wanted to start a transaction that'd access some key and then
presumably do some other work. As currently specced, here's what I'd need
to do:
myDB.transaction().objectStore(someObjectStore).index(someIndex).get(someKey).onsuccess(function()
{
anotherObjectStore.get(someOtherKey).onsuccess(...);
});
vs doing something like this:
myDB.asyncTransaction().onsuccess(function() {
myIndex.get(someKey).onsuccess(function() {
anotherObjectStore.get(someOtherKey).onsuccess(...);
});
});
With the former, we actually have more typing and the code is harder to
read. Sure, when I'm writing short code snipits, the synchronous form can
be more convenient and readable, but forcing this upon every situation is
going to be a hinderance.
Please, lets add back in a transaction method that returns an IDBRequest.
J
[widgets] Draft minutes for 5 August 2010 voice conf
The draft minutes from the August 5 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/08/05-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before August 12 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 05 Aug 2010 See also: [2]IRC log [2] http://www.w3.org/2010/08/05-wam-irc Attendees Present Art, Marcos, Josh Regrets Frederick, Kenneth, Robin Chair Art Scribe Art Contents * [3]Topics 1. [4]Review and tweak agenda 2. [5]Announcements 3. [6]Packaging and Configuration spec 4. [7]Widget Interface spec 5. [8]AOB * [9]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Review and tweak agenda AB: the draft agenda was posted a few days ago: ( [10]http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/03 44.html ). Any change requests? [10] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0344.html MC: no Announcements AB: any short announcements? [ none ] Packaging and Configuration spec AB: Marcos uploaded several I18N test cases to the PC test repository ( [11]http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/01 38.html ). ... how many I18N tests have been uploaded and are there any more? [11] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0138.html MC: we uploaded about 170 and have a few more ... we also need to remove some redundancies AB: I counted about 277 last week for all of PC MC: that sounds about right ... don't expect any more AB: what about review of the I18N tests? MC: Lachlan and one other guy at Opera reviewed them ... and I reviewed them too ... we still need to get review by the I18N WG AB: agree we should ask I18N WG for comments ... but we should wait until we are done MC: Hari Kumar will notify me when the tests are ready for I18N WG comments scribe ACTION: Marcos notify the I18N Core WG about the I18N test cases and ask them for comments [recorded in [12]http://www.w3.org/2010/08/05-wam-minutes.html#action01] trackbot Created ACTION-567 - Notify the I18N Core WG about the I18N test cases and ask them for comments [on Marcos Caceres - due 2010-08-12]. AB: Marcos also uploaded several viewmode attribute parsing test cases ( [13]http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/00 96.html ). [13] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0096.html MC: yes, those test fill a hole we had in our test suite AB: as a result of these new test cases, none of the PC implementations is even at 50% compliance ( [14]http://dev.w3.org/2006/waf/widgets/imp-report/ ). ... a question is whether or not the I18N support is optional or not [14] http://dev.w3.org/2006/waf/widgets/imp-report/ MC: no they really aren't because the parsing algorithms are now directly included in the spec ... whereas before when we pointed to the ITS spec the algorithms were external ... These new test cases are important and Lachlan did a very thorough job AB: so the UA must adhere to the syntax and parsing constraints but the UA doesn't really have any requirements on how to display internationalized attributes ... is this right? MC: yes, that's right ... how the UA displays the internationalized strings is platform specific AB: we now need to get at least 2 implementations that can pass all of the test suites ... Issue-117 ( [15]http://www.w3.org/2008/webapps/track/issues/117 ) In Widget PC Spec, need to clarify in the spec that dir attribute does not apply to attributes that are IRIs, Numeric, Keywords, etc. The dir attribute only affects human readable strings.. ... to address this issue, I believe Marcos already updated the spec with some editorial fix several weeks ago. Is this correct Marcos? [15] http://www.w3.org/2008/webapps/track/issues/117 MC: yes, I have already uploaded the fixes ... this required creating the displayable attribute ... so this issue can be closed AB: so this was editorial, right? MC: yes, definitely - it did not affect the processing AB: OK, would then please close this issue Marcos? MC: yes, I just closed it. Widget Interface spec AB: Issue-116 ( [16]http://www.w3.org/2008/webapps/track/issues/116 ) Need to flesh out the security considerations for the openURL method in the Widget Interface spec is blocking advancement of this
Re: [IndexedDB] Need a method to remove a database
On Thu, Aug 5, 2010 at 2:30 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Aug 4, 2010 at 7:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher sdwi...@mozilla.com wrote: Hey all, Some of the feedback I've been seeing on the web is that there is no way to remove a database. Examples seem to be web page wants to allow the user to remove the data they stored. A site can almost accomplish this now by removing all object stores, but we still end up storing some meta data (version number). Does this seem like a legit request to everyone? Sounds legit to me. Feel somewhat embarrassed that I've missed this so far :) Agreed. What should the semantics be for open database connections? We could do something like setVersion, but I'd just as soon nuke any existing connection (i.e. make all future operations fail). This seems reasonable since the reasons we didn't do this for setVersion (data loss) don't really seem to apply here. Actually, there could dataloss apply here. Consider a page which creates a temporary database, fills it with data, and then slowly sends it to the server. Once all data has been sent to the server the database is removed. If you have two instances of that page open, one could remove the database while the other is still writing to it. Though this seems like a pretty scary setup anyway since if the user closes the second page midway through, the first one will succeed in deleting the database no matter what. Well, presumably the site won't delete a database programmatically if it still has important information in it. I mean, the same scenario you just explained could happen with .clear() or .removeObjectStore() as well. It can with .clear(), but it can't with .removeObjectStore() since you can only call that when you have a VERSION_CHANGE transaction, which you can only get once no other connections to the database exist. / Jonas
Re: [IndexedDB] Need a method to remove a database
On Thu, Aug 5, 2010 at 10:22 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 5, 2010 at 2:30 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 4, 2010 at 7:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher sdwi...@mozilla.com
wrote:
Hey all,
Some of the feedback I've been seeing on the web is that there is no
way
to
remove a database. Examples seem to be web page wants to allow the
user to
remove the data they stored. A site can almost accomplish this now
by
removing all object stores, but we still end up storing some meta
data
(version number). Does this seem like a legit request to everyone?
Sounds legit to me. Feel somewhat embarrassed that I've missed this so
far
:)
Agreed.
What should the semantics be for open database connections? We could do
something like setVersion, but I'd just as soon nuke any existing
connection
(i.e. make all future operations fail). This seems reasonable since the
reasons we didn't do this for setVersion (data loss) don't really seem
to
apply here.
Actually, there could dataloss apply here. Consider a page which
creates a temporary database, fills it with data, and then slowly
sends it to the server. Once all data has been sent to the server the
database is removed.
If you have two instances of that page open, one could remove the
database while the other is still writing to it.
Though this seems like a pretty scary setup anyway since if the user
closes the second page midway through, the first one will succeed in
deleting the database no matter what.
Well, presumably the site won't delete a database programmatically if it
still has important information in it. I mean, the same scenario you just
explained could happen with .clear() or .removeObjectStore() as well.
It can with .clear(), but it can't with .removeObjectStore() since you
can only call that when you have a VERSION_CHANGE transaction, which
you can only get once no other connections to the database exist.
Actually, using responsible programming it can't happen with .clear()
either since you can only call that from a READ_WRITE transaction that
holds a lock on the given objectStore. So if you implement my example
as:
trans = db.transaction([mystore], READ_WRITE);
trans.objectStore(mystore).openCursor().onsuccess = function(e) {
cursor = e.result;
if (!cursor) {
// we're done, clear the store
trans.objectStore(mystore).clear();
return;
}
xhr = new XMLHttpRequest();
xhr.open(POST, uri);
xhr.send(cursor.value);
cursor.continue();
}
The only way .clear() could cause dataloss in the example I gave is if
you end your transaction after having sent all the data, and then open
a new transaction to clear the store.
I suggest we make removeDatabase (or whatever we call it) schedule a
database to be deleted, but doesn't actually delete it until all
existing connections to it are closed (though either explicit calls to
IDBDatabase.close(), or through the tab being closed).
Any calls to IDBFactory.open with the same name will hold the callback
until the removeDatabase() operation is finished. I.e. after all
existing connections are closed and the database is removed.
This is similar to how setVersion works.
/ Jonas
Re: [IndexedDB] Implicit transactions
Ok, I'm going to start by taking a step back here.
There is no such thing as implicit transactions.
db.objectStore(foo, mode)
is just syntactic sugar for
db.transaction([foo], mode).objectStore(foo)
so it always starts a new transaction. I think for now, lets take
db.objectStore(..) out of the discussion and focus on how we want
db.transaction() to work. In the end we may or may not want to keep
db.objectStore() if it causes too much confusion.
One thing that we have to first realize is that every IDBObjectStore
instance is tied to a specific transaction. This is required to avoid
ambiguity in what transaction a request is made against. Consider the
following code
trans1 = db.transaction([foo, bar], READ_WRITE);
trans2 = db.transaction([foo, students], READ_ONLY);
os1 = trans1.objectStore(foo);
os2 = trans2.objectStore(foo);
alert(os1 === os2);
os1.get(someKey).onsuccess = ...;
In this code, the alert will always display false. The os1 and os2
are two distinct objects. They have to be, otherwise we wouldn't know
which transaction to place the get() request against.
Once a transaction has been committed or aborted, using any of the
IDBObjectStore objects connected with it will throw an error. So the
example mentioned earlier in the thread (i'll use different syntax
than used previously in the thread):
var gMyos = null;
function fun1() {
gMyos = db.transaction([foo]).objectStore(foo);
gMyos.get(someKey).onsuccess = ...;
}
function fun2() {
gMyos.get(someOtherKey);
}
If we return to the main even loop between calling fun1 and fun2, the
.get() call in fun2 will *always* throw. IMHO it's a good thing that
this consistently throws. Consider also
function fun3() {
var trans = db.transaction([foo, bar], READ_WRITE);
trans.objectStore(bar).openCursor(...).onsuccess = ...;
}
It would IMHO be a bad thing if calling fun3 right before calling fun2
all of a sudden made fun2 not throw and instead place a request
against the transaction created in fun3.
While I definitely think it can be confusing that there are several
IDBObjectStore instances referring to the same underlying objectStore,
I think this is ultimately a good thing as it reduces the risk of
accidentally placing a request against the wrong transaction. It means
that in order to place a request against a transaction, you must
either have a reference to that transaction, or a reference to an
objectStore retrieved from that transaction.
Another way to think of it is this. You generally don't place requests
against an objectStore or index. You place them against a transaction.
By tying IDBObjectStores to a given transaction, it's always explicit
which transaction you are using.
On Thu, Aug 5, 2010 at 3:04 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 4, 2010 at 7:47 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 8/4/2010 10:53 AM, Jeremy Orlow wrote:
Whoatransaction() is synchronous?!? Ok, so I guess the entire
premise
of my question was super confused. :-)
It is certainly spec'd that way [1]. The locks do not get acquired until
the first actual bit of work is done though.
I fully understand how the trick works. I just didn't comprehend the fact
that the Mozilla proposal (what's now in the spec) was removing any way to
get into an IDBTransactionEvent handler besides doing an initial data
access. I wouldn't have agreed to the proposal had I realized this.
Lets say I had the following bit of initialization code in my program:
var myDB = ...
var myObjectStore = myDB.objectStore(someObjectStore);
var myIndex = myObjectStore.index(someIndex);
var anotherObjectStore = myDB.objectStore(anotherObjectStore);
As described above, grabbing references like this is not what you want
to do. If we were to allow this I think we would run a severe risk of
making it very hard to understand which transaction you are placing
requests against.
And then I wanted to start a transaction that'd access some key and then
presumably do some other work. As currently specced, here's what I'd need
to do:
myDB.transaction().objectStore(someObjectStore).index(someIndex).get(someKey).onsuccess(function()
{
anotherObjectStore.get(someOtherKey).onsuccess(...);
});
vs doing something like this:
myDB.asyncTransaction().onsuccess(function() {
myIndex.get(someKey).onsuccess(function() {
anotherObjectStore.get(someOtherKey).onsuccess(...);
});
});
With the former, we actually have more typing and the code is harder to
read. Sure, when I'm writing short code snipits, the synchronous form can
be more convenient and readable, but forcing this upon every situation is
going to be a hinderance.
Please, lets add back in a transaction method that returns an IDBRequest.
The current design of the spec is that which IDBObjectStore you place
a request against determines which transaction you are using.
It sounds to me like you want a design where each IDBObjectStore
instance represents just a objectStore
Re: [IndexedDB] Need a method to remove a database
On Thu, Aug 5, 2010 at 11:03 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Aug 5, 2010 at 6:50 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 5, 2010 at 10:22 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 5, 2010 at 2:30 AM, Jeremy Orlow jor...@chromium.org
wrote:
On Wed, Aug 4, 2010 at 7:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Aug 4, 2010 at 2:56 AM, Jeremy Orlow jor...@chromium.org
wrote:
On Tue, Aug 3, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc
wrote:
On Tue, Aug 3, 2010 at 3:20 PM, Shawn Wilsher sdwi...@mozilla.com
wrote:
Hey all,
Some of the feedback I've been seeing on the web is that there is
no
way
to
remove a database. Examples seem to be web page wants to allow
the
user to
remove the data they stored. A site can almost accomplish this
now
by
removing all object stores, but we still end up storing some meta
data
(version number). Does this seem like a legit request to
everyone?
Sounds legit to me. Feel somewhat embarrassed that I've missed this
so
far
:)
Agreed.
What should the semantics be for open database connections? We
could do
something like setVersion, but I'd just as soon nuke any existing
connection
(i.e. make all future operations fail). This seems reasonable since
the
reasons we didn't do this for setVersion (data loss) don't really
seem
to
apply here.
Actually, there could dataloss apply here. Consider a page which
creates a temporary database, fills it with data, and then slowly
sends it to the server. Once all data has been sent to the server the
database is removed.
If you have two instances of that page open, one could remove the
database while the other is still writing to it.
Though this seems like a pretty scary setup anyway since if the user
closes the second page midway through, the first one will succeed in
deleting the database no matter what.
Well, presumably the site won't delete a database programmatically if
it
still has important information in it. I mean, the same scenario you
just
explained could happen with .clear() or .removeObjectStore() as well.
It can with .clear(), but it can't with .removeObjectStore() since you
can only call that when you have a VERSION_CHANGE transaction, which
you can only get once no other connections to the database exist.
Actually, using responsible programming it can't happen with .clear()
either since you can only call that from a READ_WRITE transaction that
holds a lock on the given objectStore. So if you implement my example
as:
trans = db.transaction([mystore], READ_WRITE);
trans.objectStore(mystore).openCursor().onsuccess = function(e) {
cursor = e.result;
if (!cursor) {
// we're done, clear the store
trans.objectStore(mystore).clear();
return;
}
xhr = new XMLHttpRequest();
xhr.open(POST, uri);
xhr.send(cursor.value);
cursor.continue();
}
The only way .clear() could cause dataloss in the example I gave is if
you end your transaction after having sent all the data, and then open
a new transaction to clear the store.
I suggest we make removeDatabase (or whatever we call it) schedule a
database to be deleted, but doesn't actually delete it until all
existing connections to it are closed (though either explicit calls to
IDBDatabase.close(), or through the tab being closed).
Any calls to IDBFactory.open with the same name will hold the callback
until the removeDatabase() operation is finished. I.e. after all
existing connections are closed and the database is removed.
This is similar to how setVersion works.
If we're not going to keep it simple, then we should match the setVersion
semantics as much as is possible. I.e. add the blocked event and stuff like
that.
The blocked event fires on the IDBDatabase object. Do we want to
require that the database is opened before it can be removed? I don't
really feel strongly either way.
The other question is if we should fire a versionchange event on
other open IDBDatabases, like setVersion does. Or should we fire a
holy hell, your database is about to get nuked! event? The former
would keep things simpler since there is just one event to listen to.
The latter might be more correct.
/ Jonas
RE: [IndexedDB] Need a method to remove a database
-Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Thursday, August 05, 2010 2:12 PM I suggest we make removeDatabase (or whatever we call it) schedule a database to be deleted, but doesn't actually delete it until all existing connections to it are closed (though either explicit calls to IDBDatabase.close(), or through the tab being closed). Any calls to IDBFactory.open with the same name will hold the callback until the removeDatabase() operation is finished. I.e. after all existing connections are closed and the database is removed. This is similar to how setVersion works. If we're not going to keep it simple, then we should match the setVersion semantics as much as is possible. I.e. add the blocked event and stuff like that. The blocked event fires on the IDBDatabase object. Do we want to require that the database is opened before it can be removed? I don't really feel strongly either way. The other question is if we should fire a versionchange event on other open IDBDatabases, like setVersion does. Or should we fire a holy hell, your database is about to get nuked! event? The former would keep things simpler since there is just one event to listen to. The latter might be more correct. / Jonas I like the idea of just scheduling the database to be deleted once the last connection to it closes, and also preventing any new connection from being established once the database has been scheduled for deletion. This adds as little surface area as possible to the API. If we find that that's not a good idea for some reason, I wonder if we should unify the versionchange event and this into a single stuff seriously changed event where subscribers need to close their handles and let go of any assumptions they had about the database. Once they can re-open, they need to re-establish all their context (this is already true for a version change, we may as well extend it to database deletes and any other future big changes to the database schema, options, etc.) -pablo
Re: [IndexedDB] Need a method to remove a database
On Thu, Aug 5, 2010 at 4:02 PM, Pablo Castro pablo.cas...@microsoft.com wrote:
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jonas Sicking
Sent: Thursday, August 05, 2010 2:12 PM
I suggest we make removeDatabase (or whatever we call it) schedule a
database to be deleted, but doesn't actually delete it until all
existing connections to it are closed (though either explicit calls to
IDBDatabase.close(), or through the tab being closed).
Any calls to IDBFactory.open with the same name will hold the callback
until the removeDatabase() operation is finished. I.e. after all
existing connections are closed and the database is removed.
This is similar to how setVersion works.
If we're not going to keep it simple, then we should match the setVersion
semantics as much as is possible. I.e. add the blocked event and stuff
like
that.
The blocked event fires on the IDBDatabase object. Do we want to
require that the database is opened before it can be removed? I don't
really feel strongly either way.
The other question is if we should fire a versionchange event on
other open IDBDatabases, like setVersion does. Or should we fire a
holy hell, your database is about to get nuked! event? The former
would keep things simpler since there is just one event to listen to.
The latter might be more correct.
/ Jonas
I like the idea of just scheduling the database to be deleted once the last
connection to it closes, and also preventing any new connection from being
established once the database has been scheduled for deletion. This adds as
little surface area as possible to the API.
If we find that that's not a good idea for some reason, I wonder if we should
unify the versionchange event and this into a single stuff seriously
changed event where subscribers need to close their handles and let go of
any assumptions they had about the database. Once they can re-open, they need
to re-establish all their context (this is already true for a version change,
we may as well extend it to database deletes and any other future big changes
to the database schema, options, etc.)
Here's my proposal, please poke holes in it:
interface IDBFactory {
...
IDBRequest deleteDatabase(in DOMString name);
...
};
When deleteDatabase is called, the given database is scheduled for
deletion. If any IDBDatabase objects are opened to the database fire a
versionchange event on those IDBDatabase objects, with a .version
set to null. If any calls to IDBFactory.open occur, stall those until
after this algorithm is finished. Note that this generally won't mean
that those open calls will fail. They'll generally will receive a
newly created database instead.
Once all existing IDBDatabase are closed (implicitly or explicitly),
the database is removed. At this point any IDBFactory.open calls are
fulfilled and a success event is fired on the returned IDBRequest.
So no blocked event is fired as I'm not sure where to fire it. I'm
also not sure that this is a big problem. I'm not even sure that
returning a IDBRequest is worth it. The only value I can see is
wanting to display to a user when a database is for sure deleted as to
allow the user to for example safely shut down the computer without
worrying that sensitive data is still in the database.
/ Jonas
[Bug 10302] New: Introduce exception handlers at the transaction/database scope
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10302 Summary: Introduce exception handlers at the transaction/database scope Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org In many cases error handling will the same for most database access points throughout an application, so having a hierarchy of error handlers would have a good effect in reducing redundant setup of error handlers all over the code. As proposed by Jonas we could have operation-, transaction- and database-scoped error handlers. I'm not sure about tying up .preventDefault() to wether the trasaction gets aborted because you may just want to stop the event from bubbling, but we can discuss this when we come up with the actual write up for this for the spec. Snippet from relevant thread[1] copied below. Somewhat unrelated, but I wonder if we should consider a global (per database session) error handler or something like that. Database operations are just too granular, so maybe the usual deal where you setup an error handler per-operation is not the right thing to do. This is a great idea. What we could do is to first fire the 'error' event on the IDBRequest. If .preventDefault() is not called, we'll fire an 'error' event on the IDBTransaction. If .preventDefault() still hasn't been called, we fire an 'error' event on the IDBDatabase. If .preventDefault() *still* hasn't been called, we roll back the transaction. This is very similar to error handling in Workers. It might be overly complex implementation wise, but it does seem like a nice API for authors. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0231.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
