Re: [IndexedDB] Need a method to remove a database
On Fri, Aug 6, 2010 at 12:37 AM, Jonas Sicking jo...@sicking.cc wrote:
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.
All of this sounds good to me. I'd probably still return an IDBRequest
for consistency and so that the app can get a conformation when it's really
gone. On success would fire with a null result field, I'd think.
J
[widgets] Test Suites
Hi All, Hari, from Opera, has cleaned up the PC test suite. We removed some redundant tests (that were not part of the test-suite.xml) and corrected a few i18n tests. We are still validating the i18n tests, but hope to finish soon. We also have WARP tests about to be submitted and Dig Sigs test suite is about 1 week out from being uploaded! More details coming soon. Kind regards, Marcos -- Marcos Caceres Opera Software
[Bug 10304] New: Rename remove method on object store to delete
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10304 Summary: Rename remove method on object store to delete Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: k...@sitepen.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Based on the mailing list discussion, it was generally agreed that we could rename the remove method on the object store API back to it's original name of delete. This was originally renamed due to EcmaScript reserved word concern, but since all implementations are targeting EcmaScript 5, and delete is contextually unreserved in ES5, the use of delete is perfectly fine, and the most clear word for the action of the method. -- 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.
Re: [Bug 10302] New: Introduce exception handlers at the transaction/database scope
On Fri, Aug 6, 2010 at 2:07 AM, bugzi...@jessica.w3.org wrote: 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. Interesting. So I assume that when we talk about bubbling, we're saying that we'd go up the chain of what spawned the object. For example, IDBObjectStore would raise (if appropriate) to just the IDBTransaction object that spawned it, correct? And even if the IDBTransaction object that spawned it were created implicitly by IDBDatabase.objectStore, we still would, right? If so, SGTM. J
[Bug 10305] New: [IndexedDB] Transactions need to be clarified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10305 Summary: [IndexedDB] Transactions need to be clarified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org It seems that we weren't all on the same page in terms of how transactions were supposed to work. I think it was agreed that the language is a bit vague and that we should put more detail in the spec about how they should work. Jonas' email [1] on the thread ([IndexedDB] Implicit transactions) probably sums the expected behavior up best. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0376.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.
Re: [IndexedDB] Implicit transactions
On Fri, Aug 6, 2010 at 1:56 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Aug 5, 2010 at 8:56 PM, Jonas Sicking jo...@sicking.cc wrote:
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
Re: [IndexedDB] Implicit transactions
On Fri, Aug 6, 2010 at 1:56 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Aug 5, 2010 at 8:56 PM, Jonas Sicking jo...@sicking.cc wrote:
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
Re: [IndexedDB] Implicit transactions
On Fri, Aug 6, 2010 at 6:52 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 6, 2010 at 1:56 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Aug 5, 2010 at 8:56 PM, Jonas Sicking jo...@sicking.cc wrote:
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
Re: [IndexedDB] Implicit transactions
On Fri, Aug 6, 2010 at 4:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 6, 2010 at 6:52 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 6, 2010 at 1:56 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Thu, Aug 5, 2010 at 8:56 PM, Jonas Sicking jo...@sicking.cc wrote:
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
Re: [IndexedDB] Implicit transactions
On Fri, Aug 6, 2010 at 8:06 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 6, 2010 at 4:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 6, 2010 at 6:52 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Aug 6, 2010 at 1:56 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Thu, Aug 5, 2010 at 8:56 PM, Jonas Sicking jo...@sicking.cc wrote:
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() {
[Bug 10307] New: [indexedDB] The default version string is not specified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10307 Summary: [indexedDB] The default version string is not specified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org When you create a new database, we need to specify what the version string defaults to. might be a good answer. -- 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.
Re: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group)
On 8/5/10 3:30 PM, Web Applications Working Group Issue Tracker wrote: ACTION-568: Create an alternative mechanism for openURL and send it to the mail list (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/568 On: Marcos Caceres Due: 2010-08-12 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/39125#settings The proposal is simply to use HTML a element. So, instead of: widget.openURL(sms:+123456789101112); It would just be: a href=sms:+123456789101112Send and SMS/a Then you can use the .click() element to open links programmatically (on trusted URI types) or only respond to explicit user interaction (the user clicks on the link to do something). Kind regards, Marcos -- Marcos Caceres Opera Software
Re: [Bug 10302] New: Introduce exception handlers at the transaction/database scope
On Fri, Aug 6, 2010 at 5:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 6, 2010 at 2:07 AM, bugzi...@jessica.w3.org wrote: 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. Interesting. So I assume that when we talk about bubbling, we're saying that we'd go up the chain of what spawned the object. For example, IDBObjectStore would raise (if appropriate) to just the IDBTransaction object that spawned it, correct? And even if the IDBTransaction object that spawned it were created implicitly by IDBDatabase.objectStore, we still would, right? If so, SGTM. Yeah, the way I initially described it was different, but the more I think about it, the more I think we should set up a real event propagation path. So the error event will first go through a capture phase from the IDBDatabase - IDBTransaction - IDBRequest and then a bubble phase IDBRequest - IDBTransaction - IDBDatabase (technically I think that at the IDBRequest it's in the target phase, not any of the other phases). I wasn't envisioning including IDBObjectStore or IDBIndex in the chain. Is there a reason to? If so, would we also include IDBCursor? / Jonas
