Re: [WebIDL] interface objects and properties too restrictive?
On Aug 3, 2010, at 4:57 PM, Travis Leithead wrote:
Hey folks, just wondering what the justification behind the current
{DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet) [2].
When our IE9 binding ported this to ES5, it translated to configurable:
false, which completely destroyed the ability to set accessors on the
interface objects as well as operations (and in our case, DOM accessors).
Because of this, we actually don't mark our interface objects OR
operations/attributes as configurable: false, rather configurable: true.*
I'm a little confused about what you mean and how it relates to the spec. To
clarify what the spec actually says:
If this seems reasonable, I'd like to see the spec updated.
-Travis
*special exceptions apply :-)
[1]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WebIDL/Overview.html?rev=1.206content-type=text/html;
charset=iso-8859-1#es-interfaces
In this case, what's DontDelete is the property on the global object that
represents the interface object. For example, for the HTMLElement interface, it
would be the property window.HTMLElement. This should have no effect on making
use of the object assigned to that property. It just means you can't alter that
property of the Window object, other than to change its value.
[2]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WebIDL/Overview.html?rev=1.206content-type=text/html;
charset=iso-8859-1#host-objects
And in this case, DontDelete only applies to readonly attributes. It seems
correct and indeed required that you can't delete a readonly attribute or
reconfigure it in other ways. An example of a readonly attribute in HTML5 is
HTMLDocument.URL. It would (obviously I hope) make no sense to delete
Document.URL or replace it with a setter.
I don't see how this completely destroy[s] the ability to set accessors. You
can still add a setter to HTMLElement.prototype.
Regards,
Maciej
Re: [IndexedDB] Need a method to clear an object store
On Tue, Aug 3, 2010 at 11:02 PM, ben turner bent.mozi...@gmail.com wrote: On Tue, Aug 3, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote: I think there is a bug in the above proposal though. clear() should return a IDBRequest. However the .result of the request should likely be null. Yes, definitely. My fingers were too fast for my brain. I think adding a clear seems reasonable and shouldn't be that much overhead or surface area. J
[IndexedDB] Implicit transactions
In the IndexedDB spec, there are two ways to create a transaction. One is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before bringing these up, I think it might
be best to give a bit of background (as I understand it) to make sure we're
all on the same page:
*Belief 1:*
No matter how the transaction is started, any subsequent calls done within
an IDBTransactionEvent (which is the event fired for almost every
IDBRequest.onsuccess call since almost all of them are for operations done
within the context of a transaction) will continue running in the same
transaction. So, for example, the following code will atomically increment
a counter:
myDB.transaction().onsuccess(function() {
myDB.objectStore(someObjectStore).get(counter).onsuccess(function()
{
myDB.objectStore(someObjectStore).put(counter, event.result +
1);
});
});
*Belief 2:*
Let's say I ran the following code:
myDB.transaction().onsuccess(function() { window.myObjectStore =
myDB.objectStore(someObjectStore); /* do some other work */ });
And then at any point later in the program (after that first transaction had
committed) I could do the following:
myDB.transaction().onsuccess(function() { window.myObjectStore.get(some
value).onsuccess(...); });
Even though myObjectStore was originally fetched during some other
transaction, it's quite clear that I'm accessing values from that object
store in this new transaction's context, and thus that's exactly what
happens and this is allowed.
*Implicitly created transactions:*
At a high level, the intent is for
IDBDatabase.objectStore.get(someKey).onsuccess(...); to just work, even
when not called in an IDBTransactionEvent handler. But what happens if I
run the following code (outside of an IDBTransactionEvent handler):
for (var i=0; i5; ++i)
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...);
Do we want that to create 5 separate transactions or 5 requests within the
same transaction?
And what if we run my earlier example (that stored an object store to
window.myObjectStore within a transaction we started explicitly) and then
run the following code (outside of an IDBTransactionEventHandler):
window.myObjectStore.get(someKey).onsuccess(...);
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...)
Should both be legal? Will this create one or two transactions?
*Speccing such transactions:*
After thinking about this, I only see a couple options for how to spec
implicitly created transactions:
When an operation that needs to be done in a transaction (i.e. anything
that touches data) is done outside of an IDBTransactionEvent handler...
1) that operation will be done in its own, newly created transaction.
2) if there already exists an implicitly created transaction for that
objectStore, it'll be done in that transaction. Otherwise a new one will be
created.
3) if there already exists _any_ transaction with access to that
objectStore, it'll be done in that transaction. Otherwise a new one will be
created.
2 seems like it'd match the users intention in a lot of cases, but its
biggest problem is that it's non-deterministic. If you do one .get() and
then set a time out and do another, you don't know whether they'll be in the
same transaction or not. 3 seems to have the same problem except it's even
less predictable. So, but process of elimination, it seems as though 1 is
our only option in terms of how to spec this. Or am I missing something?
*Read-only by default too?*
Another somewhat related question: should implicitly created transactions be
read-only (which is the default for explicitly created ones)? If so, that
means that we expect the following to fail:
myDB.objectStore(someObjectStore).get(counter).onsuccess(function() {
myDB.objectStore(someObjectStore).put(counter, event.result + 1);
});
Unfortunately, it seems as though a lot of use cases for implicitly created
transactions would involve more than just reads. But if we spec that to
succeed, then we're lowering concurrency and making things inconsistent with
the default for IDBDatabase.transaction(), right?
*Conclusion:*
Am I missing something here? Or will properly speccing implicitly created
transactions lead to them being nearly useless for the simple use cases we
were trying to make simpler to begin with?
J
Re: [IndexedDB] Implicit transactions
On Wed, Aug 4, 2010 at 4:42 PM, Jeremy Orlow jor...@chromium.org wrote:
In the IndexedDB spec, there are two ways to create a transaction. One is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before bringing these up, I think it might
be best to give a bit of background (as I understand it) to make sure we're
all on the same page:
Belief 1:
No matter how the transaction is started, any subsequent calls done within
an IDBTransactionEvent (which is the event fired for almost every
IDBRequest.onsuccess call since almost all of them are for operations done
within the context of a transaction) will continue running in the same
transaction. So, for example, the following code will atomically increment
a counter:
myDB.transaction().onsuccess(function() {
myDB.objectStore(someObjectStore).get(counter).onsuccess(function()
{
myDB.objectStore(someObjectStore).put(counter, event.result +
1);
});
});
Belief 2:
Let's say I ran the following code:
myDB.transaction().onsuccess(function() { window.myObjectStore =
myDB.objectStore(someObjectStore); /* do some other work */ });
And then at any point later in the program (after that first transaction had
committed) I could do the following:
myDB.transaction().onsuccess(function() { window.myObjectStore.get(some
value).onsuccess(...); });
Even though myObjectStore was originally fetched during some other
transaction, it's quite clear that I'm accessing values from that object
store in this new transaction's context, and thus that's exactly what
happens and this is allowed.
I think it's only allowed as long as the object store in question is
in the scope of this other transaction.
Implicitly created transactions:
At a high level, the intent is
for IDBDatabase.objectStore.get(someKey).onsuccess(...); to just work,
even when not called in an IDBTransactionEvent handler. But what happens if
I run the following code (outside of an IDBTransactionEvent handler):
for (var i=0; i5; ++i)
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...);
Do we want that to create 5 separate transactions or 5 requests within the
same transaction?
As currently specced, I think that would indeed start 5 separate
transactions. But couldn't you save the object store in a variable
before the loop?
And what if we run my earlier example (that stored an object store to
window.myObjectStore within a transaction we started explicitly) and then
run the following code (outside of an IDBTransactionEventHandler):
window.myObjectStore.get(someKey).onsuccess(...);
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...)
Should both be legal? Will this create one or two transactions?
I think simply calling window.myObjectStore.get() would not create a
transaction. I think it would just throw?
myDB.objectStore().get() would create a transaction.
Speccing such transactions:
After thinking about this, I only see a couple options for how to spec
implicitly created transactions:
When an operation that needs to be done in a transaction (i.e. anything
that touches data) is done outside of an IDBTransactionEvent handler...
1) that operation will be done in its own, newly created transaction.
2) if there already exists an implicitly created transaction for that
objectStore, it'll be done in that transaction. Otherwise a new one will be
created.
3) if there already exists _any_ transaction with access to that
objectStore, it'll be done in that transaction. Otherwise a new one will be
created.
2 seems like it'd match the users intention in a lot of cases, but its
biggest problem is that it's non-deterministic. If you do one .get() and
then set a time out and do another, you don't know whether they'll be in the
same transaction or not.
That's right, it seems like a problem to me.
3 seems to have the same problem except it's even
less predictable. So, but process of elimination, it seems as though 1 is
our only option in terms of how to spec this. Or am I missing something?
Well, what's wrong with what's specced today:
- you can only call get/put/etc in the context of a transaction. If
you don't, they'll throw.
- in the context of a transaction means in a transaction callback or
after you created an implicit transaction and until control returns to
the main browser event loop.
Read-only by default too?
Another somewhat related question: should implicitly created transactions be
read-only (which is the default for explicitly created ones)? If so, that
means that we expect the following to fail:
myDB.objectStore(someObjectStore).get(counter).onsuccess(function() {
myDB.objectStore(someObjectStore).put(counter, event.result + 1);
});
Unfortunately, it seems as though a lot of use cases for implicitly created
transactions would involve more than just reads. But if we
Re: [IndexedDB] Implicit transactions
On Wed, Aug 4, 2010 at 5:26 PM, Andrei Popescu andr...@google.com wrote:
On Wed, Aug 4, 2010 at 4:42 PM, Jeremy Orlow jor...@chromium.org wrote:
In the IndexedDB spec, there are two ways to create a transaction. One
is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before bringing these up, I think it
might
be best to give a bit of background (as I understand it) to make sure
we're
all on the same page:
Belief 1:
No matter how the transaction is started, any subsequent calls done
within
an IDBTransactionEvent (which is the event fired for almost every
IDBRequest.onsuccess call since almost all of them are for operations
done
within the context of a transaction) will continue running in the same
transaction. So, for example, the following code will atomically
increment
a counter:
myDB.transaction().onsuccess(function() {
myDB.objectStore(someObjectStore).get(counter).onsuccess(function()
{
myDB.objectStore(someObjectStore).put(counter, event.result +
1);
});
});
Belief 2:
Let's say I ran the following code:
myDB.transaction().onsuccess(function() { window.myObjectStore =
myDB.objectStore(someObjectStore); /* do some other work */ });
And then at any point later in the program (after that first transaction
had
committed) I could do the following:
myDB.transaction().onsuccess(function() { window.myObjectStore.get(some
value).onsuccess(...); });
Even though myObjectStore was originally fetched during some other
transaction, it's quite clear that I'm accessing values from that object
store in this new transaction's context, and thus that's exactly what
happens and this is allowed.
I think it's only allowed as long as the object store in question is
in the scope of this other transaction.
Of course. (I should have explicitly mentioned that though.)
Implicitly created transactions:
At a high level, the intent is
for IDBDatabase.objectStore.get(someKey).onsuccess(...); to just
work,
even when not called in an IDBTransactionEvent handler. But what happens
if
I run the following code (outside of an IDBTransactionEvent handler):
for (var i=0; i5; ++i)
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...);
Do we want that to create 5 separate transactions or 5 requests within
the
same transaction?
As currently specced, I think that would indeed start 5 separate
transactions. But couldn't you save the object store in a variable
before the loop?
To be clear, you're suggesting that the following would result in 1
transaction?
var myOS = myDB.objectStore(someObjectStore);
for (var i=0; i5; ++i)
myOS.get(someKey).onsuccess(...);
This would seem to imply that, when used outside of an IDBTransactionEvent
context, each instance of an objectStore object will be linked to its own
transaction? I'd assume that any children (for example IDBIndex objects)
that come from that IDBObjectStore would also be linked to the same
transaction?
What about the following:
var myOS = myDB.objectStore(someObjectStore);
myOS.get(someKey).onsuccess(...);
/* do other stuff for a while...onsuccess above fired and thus the
implicitly created transaction was committed implicitly */
myOS.get(anotherKey).onsuccess(...);
The implicitly created transaction has completed before the second .get()
call. Would the second call throw or would it start another implicit
transaction?
And what if we run my earlier example (that stored an object store to
window.myObjectStore within a transaction we started explicitly) and then
run the following code (outside of an IDBTransactionEventHandler):
window.myObjectStore.get(someKey).onsuccess(...);
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...)
Should both be legal? Will this create one or two transactions?
I think simply calling window.myObjectStore.get() would not create a
transaction. I think it would just throw?
myDB.objectStore().get() would create a transaction.
If the second .get in my last example would fail (i.e. ObjectStores are
somehow bound to a transaction, and once that transaction finishes, it
cannot be used outside of an IDBTransactionEvent context), then I could see
this making sense. Otherwise could you please explain why this is?
Speccing such transactions:
After thinking about this, I only see a couple options for how to spec
implicitly created transactions:
When an operation that needs to be done in a transaction (i.e. anything
that touches data) is done outside of an IDBTransactionEvent handler...
1) that operation will be done in its own, newly created transaction.
2) if there already exists an implicitly created transaction for that
objectStore, it'll be done in that transaction. Otherwise a new one will
be
created.
3) if there already exists _any_ transaction
Re: [IndexedDB] Implicit transactions
On Wed, Aug 4, 2010 at 5:46 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 4, 2010 at 5:26 PM, Andrei Popescu andr...@google.com wrote:
On Wed, Aug 4, 2010 at 4:42 PM, Jeremy Orlow jor...@chromium.org wrote:
In the IndexedDB spec, there are two ways to create a transaction. One
is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before bringing these up, I think it
might
be best to give a bit of background (as I understand it) to make sure
we're
all on the same page:
Belief 1:
No matter how the transaction is started, any subsequent calls done
within
an IDBTransactionEvent (which is the event fired for almost every
IDBRequest.onsuccess call since almost all of them are for operations
done
within the context of a transaction) will continue running in the same
transaction. So, for example, the following code will atomically
increment
a counter:
myDB.transaction().onsuccess(function() {
myDB.objectStore(someObjectStore).get(counter).onsuccess(function()
{
myDB.objectStore(someObjectStore).put(counter, event.result
+
1);
});
});
Belief 2:
Let's say I ran the following code:
myDB.transaction().onsuccess(function() { window.myObjectStore =
myDB.objectStore(someObjectStore); /* do some other work */ });
And then at any point later in the program (after that first transaction
had
committed) I could do the following:
myDB.transaction().onsuccess(function() { window.myObjectStore.get(some
value).onsuccess(...); });
Even though myObjectStore was originally fetched during some other
transaction, it's quite clear that I'm accessing values from that object
store in this new transaction's context, and thus that's exactly what
happens and this is allowed.
I think it's only allowed as long as the object store in question is
in the scope of this other transaction.
Of course. (I should have explicitly mentioned that though.)
Implicitly created transactions:
At a high level, the intent is
for IDBDatabase.objectStore.get(someKey).onsuccess(...); to just
work,
even when not called in an IDBTransactionEvent handler. But what
happens if
I run the following code (outside of an IDBTransactionEvent handler):
for (var i=0; i5; ++i)
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...);
Do we want that to create 5 separate transactions or 5 requests within
the
same transaction?
As currently specced, I think that would indeed start 5 separate
transactions. But couldn't you save the object store in a variable
before the loop?
To be clear, you're suggesting that the following would result in 1
transaction?
var myOS = myDB.objectStore(someObjectStore);
for (var i=0; i5; ++i)
myOS.get(someKey).onsuccess(...);
This would seem to imply that, when used outside of an IDBTransactionEvent
context, each instance of an objectStore object will be linked to its own
transaction? I'd assume that any children (for example IDBIndex objects)
that come from that IDBObjectStore would also be linked to the same
transaction?
That's my understanding, yes.
What about the following:
var myOS = myDB.objectStore(someObjectStore);
myOS.get(someKey).onsuccess(...);
/* do other stuff for a while...onsuccess above fired and thus the
implicitly created transaction was committed implicitly */
myOS.get(anotherKey).onsuccess(...);
The implicitly created transaction has completed before the second .get()
call. Would the second call throw or would it start another implicit
transaction?
My understanding is that it would throw.
And what if we run my earlier example (that stored an object store to
window.myObjectStore within a transaction we started explicitly) and
then
run the following code (outside of an IDBTransactionEventHandler):
window.myObjectStore.get(someKey).onsuccess(...);
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...)
Should both be legal? Will this create one or two transactions?
I think simply calling window.myObjectStore.get() would not create a
transaction. I think it would just throw?
myDB.objectStore().get() would create a transaction.
If the second .get in my last example would fail (i.e. ObjectStores are
somehow bound to a transaction, and once that transaction finishes, it
cannot be used outside of an IDBTransactionEvent context), then I could see
this making sense. Otherwise could you please explain why this is?
Yes, it would throw as that object store is no longer in the scope of
any transaction.
Speccing such transactions:
After thinking about this, I only see a couple options for how to spec
implicitly created transactions:
When an operation that needs to be done in a transaction (i.e. anything
that touches data) is done outside of an IDBTransactionEvent handler...
1) that
Re: [IndexedDB] Implicit transactions
I talked to Andrei in person. He seemed to think this was discussed and
agreed upon sometime earlier but agreed the spec could be more clear.
On Wed, Aug 4, 2010 at 5:46 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 4, 2010 at 5:26 PM, Andrei Popescu andr...@google.com wrote:
On Wed, Aug 4, 2010 at 4:42 PM, Jeremy Orlow jor...@chromium.org wrote:
In the IndexedDB spec, there are two ways to create a transaction. One
is
explicit (by calling IDBDatabase.transaction()) and one is implicit (for
example, by calling IDBDatabase.objectStore.get(someKey)). I have
questions about the latter, but before bringing these up, I think it
might
be best to give a bit of background (as I understand it) to make sure
we're
all on the same page:
Belief 1:
No matter how the transaction is started, any subsequent calls done
within
an IDBTransactionEvent (which is the event fired for almost every
IDBRequest.onsuccess call since almost all of them are for operations
done
within the context of a transaction) will continue running in the same
transaction. So, for example, the following code will atomically
increment
a counter:
myDB.transaction().onsuccess(function() {
myDB.objectStore(someObjectStore).get(counter).onsuccess(function()
{
myDB.objectStore(someObjectStore).put(counter, event.result
+
1);
});
});
Belief 2:
Let's say I ran the following code:
myDB.transaction().onsuccess(function() { window.myObjectStore =
myDB.objectStore(someObjectStore); /* do some other work */ });
And then at any point later in the program (after that first transaction
had
committed) I could do the following:
myDB.transaction().onsuccess(function() { window.myObjectStore.get(some
value).onsuccess(...); });
Even though myObjectStore was originally fetched during some other
transaction, it's quite clear that I'm accessing values from that object
store in this new transaction's context, and thus that's exactly what
happens and this is allowed.
I think it's only allowed as long as the object store in question is
in the scope of this other transaction.
Of course. (I should have explicitly mentioned that though.)
Implicitly created transactions:
At a high level, the intent is
for IDBDatabase.objectStore.get(someKey).onsuccess(...); to just
work,
even when not called in an IDBTransactionEvent handler. But what
happens if
I run the following code (outside of an IDBTransactionEvent handler):
for (var i=0; i5; ++i)
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...);
Do we want that to create 5 separate transactions or 5 requests within
the
same transaction?
As currently specced, I think that would indeed start 5 separate
transactions. But couldn't you save the object store in a variable
before the loop?
To be clear, you're suggesting that the following would result in 1
transaction?
var myOS = myDB.objectStore(someObjectStore);
for (var i=0; i5; ++i)
myOS.get(someKey).onsuccess(...);
This would seem to imply that, when used outside of an IDBTransactionEvent
context, each instance of an objectStore object will be linked to its own
transaction? I'd assume that any children (for example IDBIndex objects)
that come from that IDBObjectStore would also be linked to the same
transaction?
What about the following:
var myOS = myDB.objectStore(someObjectStore);
myOS.get(someKey).onsuccess(...);
/* do other stuff for a while...onsuccess above fired and thus the
implicitly created transaction was committed implicitly */
myOS.get(anotherKey).onsuccess(...);
The implicitly created transaction has completed before the second .get()
call. Would the second call throw or would it start another implicit
transaction?
Andrei said the second .get (assuming the code is not literal...since
there's no way an onsuccess could fire unless we returned control to
JavaScript) should not fire.
And what if we run my earlier example (that stored an object store to
window.myObjectStore within a transaction we started explicitly) and
then
run the following code (outside of an IDBTransactionEventHandler):
window.myObjectStore.get(someKey).onsuccess(...);
myDB.objectStore(someObjectStore).get(someKey).onsuccess(...)
Should both be legal? Will this create one or two transactions?
I think simply calling window.myObjectStore.get() would not create a
transaction. I think it would just throw?
myDB.objectStore().get() would create a transaction.
If the second .get in my last example would fail (i.e. ObjectStores are
somehow bound to a transaction, and once that transaction finishes, it
cannot be used outside of an IDBTransactionEvent context), then I could see
this making sense. Otherwise could you please explain why this is?
This does seem to be loosely what's intended...more below...
Speccing such transactions:
After thinking about this, I only see a couple options
Re: [IndexedDB] Implicit transactions
On 8/4/2010 10:24 AM, Jeremy Orlow wrote: Jonas/Shawn: Since it seems you've been getting some feedback on your implementation, do you have any data to suggest that implicit transactions are being used and considered helpful in the wild? I have not yet seen any specific feedback about it as of yet. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
RE: [IndexedDB] Need a method to remove a database
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Wednesday, August 04, 2010 2:56 AM 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. J +1 Nuking is fine...another option would be to queue up the delete until all database sessions are gone, but probably will complicate things and not add much. The only thing I wonder is if we'll create a bunch of pain for implementations where nuking is tricky (thinking of multi-process scenarios where maybe files are locked or something). -pablo
Re: [IndexedDB] Implicit transactions
On 8/4/2010 8:42 AM, Jeremy Orlow wrote: In the IndexedDB spec, there are two ways to create a transaction. One is explicit (by calling IDBDatabase.transaction()) and one is implicit (for example, by calling IDBDatabase.objectStore.get(someKey)). I have questions about the latter, but before bringing these up, I think it might be best to give a bit of background (as I understand it) to make sure we're all on the same page: If I recall correctly, the original proposal from us basically said that IDBDatabase.objectStore(foo, [mode]) was just a shortcut for IDBDatabase.transaction(foo, [mode]).getObjectStore(foo); I'm not sure if putting some text like that would help make things clearer though. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
RE: [IndexedDB] Need a method to clear an object store
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jonas Sicking
Sent: Tuesday, August 03, 2010 12:21 PM
On Tue, Aug 3, 2010 at 12:09 PM, ben turner bent.mozi...@gmail.com wrote:
Hi folks,
Currently there are only two ways to clear an object store of all
data: (i) remove the object store and recreate it, or (ii) open a
cursor and call remove for all entries. I propose a third, simpler
approach:
interface IDBObjectStore
{
...
void clear();
...
};
Any thoughts?
Some background. At least in our implementation, removing each
individual item is significantly slower than removing and recreating
the objectStore. It's also significantly slower than a 'clear'
function is. And while tearing down and recreating the objectStore
works, it's fairly complex if there are multiple indexes on the store.
Adding a clear() function, while redundant, should make things easier
for developers while adding very little work in the implementation.
I think there is a bug in the above proposal though. clear() should
return a IDBRequest. However the .result of the request should likely
be null.
/ Jonas
+1 on having clear(). We ran into the need also while playing with samples and
such.
-pablo
Re: [IndexedDB] Implicit transactions
On Wed, Aug 4, 2010 at 6:33 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 8/4/2010 8:42 AM, Jeremy Orlow wrote: In the IndexedDB spec, there are two ways to create a transaction. One is explicit (by calling IDBDatabase.transaction()) and one is implicit (for example, by calling IDBDatabase.objectStore.get(someKey)). I have questions about the latter, but before bringing these up, I think it might be best to give a bit of background (as I understand it) to make sure we're all on the same page: If I recall correctly, the original proposal from us basically said that IDBDatabase.objectStore(foo, [mode]) was just a shortcut for IDBDatabase.transaction(foo, [mode]).getObjectStore(foo); I'm not sure if putting some text like that would help make things clearer though. Whoatransaction() is synchronous?!? Ok, so I guess the entire premise of my question was super confused. :-) But I'm not sure I like that at all since it means that I will have to open at least one object store every time I do any transaction. I.e. I can't save my favorite object stores and indexes to variables and then use them freely within transactions, which is something I expect most users will want want to do. Having a cute shortcut to cut down on one async call per transaction might be a good idea. But forcing me to call .objectStore() (and possibly .index() or others) for the first operation of every transaction seems sub-optimal. I can double check with some real web developers around Google, but I'm pretty sure they'll much rather make an asynchronous call to start a transaction to get back execution within an IDBTransactionEvent context rather than having to do repeated objectStore() and .index() calls to start every single transaction. And the more I think about this, the more I'm skeptical that any sort of synchronous transaction starting code is worth the complicated semantics. I mean, in reality, it saves very little code. And although it makes sample code a bit prettier to look at (I believe this was one of the original selling points), I think it's going to confuse developers more than it'll help them--in the long run. J
[IndexedDB] IndexedDB Sample Code Documentation Tool
Hey guys, Someone just posted a link to this on one of our blog posts about IndexedDB and I figured I'd share it with the list since it's pretty darn neat: http://tinyurl.com/ff-idxdb It appears to be sample code + documentation mixed together. It does seem to be a bit specific to our implementation, but I'm sure that can be improved. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Need a method to remove a database
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. / Jonas
RE: [WebIDL] interface objects and properties too restrictive?
Sure.
Not only does ES5's configurable: false property prevent deletion, but it also
prevents changing a property from a field to an accessor and vice-versa, as
well as changing the getter/setters of the property.
So, the following wouldn't work if the appendChild property was
configurable:false:
Object.defineProperty(Node.prototype,
appendChild,
{ get: function() { /* custom getter replacement */ },
set: function(x) { /* custom setter replacement */ }
});
... which is the ES5 way of doing:
Node.prototype.__defineGetter__(appendChild, function() { /* custom getter
replacement */ });
Node.prototype.__defineSetter__(appendChild, function(x) { /* custom setter
replacement */ });
So, configurable: false prevents users from replacing built-in properties with
getter/setters. I think this is too restrictive, especially forward-looking
considering how much the DOM is changing and evolving.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, August 03, 2010 5:22 PM
To: Travis Leithead
Cc: Cameron McCormack; Sam Weinig (wei...@apple.com); public-webapps@w3.org
Subject: Re: [WebIDL] interface objects and properties too restrictive?
On Tue, Aug 3, 2010 at 4:57 PM, Travis Leithead tra...@microsoft.com wrote:
Hey folks, just wondering what the justification behind the current
{DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet)
[2]. When our IE9 binding ported this to ES5, it translated to
configurable: false, which completely destroyed the ability to set
accessors on the interface objects as well as operations (and in our
case, DOM accessors). Because of this, we actually don't mark our
interface objects OR operations/attributes as configurable: false,
rather configurable: true.*
If this seems reasonable, I'd like to see the spec updated.
Sorry, I'm not very updated on the differences between the ES3 and ES5 worlds.
Why does configurable: false destroyed the ability to set accessors? Can you
give an example of a piece of script that doesn't work but which you'd like to
work, and what you'd like it to do?
/ Jonas
Re: [IndexedDB] Implicit transactions
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. Cheers, Shawn [1] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#database-interface smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Implicit transactions
For what it's worth I haven't found using it this way to be that hard or confusing but that could be because I'm a little more aware of the underlying implications when opening object stores. -Mikeal On Wed, Aug 4, 2010 at 11:47 AM, 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. Cheers, Shawn [1] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#database-interface
Please use public-script-coord mail list for Web IDL
Hi All,
Please use public-script-coord for Web IDL.
-Thanks, AB
Original Message
Subject:RE: [WebIDL] interface objects and properties too restrictive?
Date: Wed, 4 Aug 2010 20:36:00 +0200
From: ext Travis Leithead tra...@microsoft.com
To: Jonas Sicking jo...@sicking.cc
CC: Cameron McCormack c...@mcc.id.au, Sam Weinig (wei...@apple.com)
wei...@apple.com, public-webapps@w3.org public-webapps@w3.org
Sure.
Not only does ES5's configurable: false property prevent deletion, but it also
prevents changing a property from a field to an accessor and vice-versa, as
well as changing the getter/setters of the property.
So, the following wouldn't work if the appendChild property was
configurable:false:
Object.defineProperty(Node.prototype,
appendChild,
{ get: function() { /* custom getter replacement */ },
set: function(x) { /* custom setter replacement */ }
});
... which is the ES5 way of doing:
Node.prototype.__defineGetter__(appendChild, function() { /* custom getter
replacement */ });
Node.prototype.__defineSetter__(appendChild, function(x) { /* custom setter
replacement */ });
So, configurable: false prevents users from replacing built-in properties with
getter/setters. I think this is too restrictive, especially forward-looking
considering how much the DOM is changing and evolving.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, August 03, 2010 5:22 PM
To: Travis Leithead
Cc: Cameron McCormack; Sam Weinig (wei...@apple.com); public-webapps@w3.org
Subject: Re: [WebIDL] interface objects and properties too restrictive?
On Tue, Aug 3, 2010 at 4:57 PM, Travis Leitheadtra...@microsoft.com wrote:
Hey folks, just wondering what the justification behind the current
{DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet)
[2]. When our IE9 binding ported this to ES5, it translated to
configurable: false, which completely destroyed the ability to set
accessors on the interface objects as well as operations (and in our
case, DOM accessors). Because of this, we actually don't mark our
interface objects OR operations/attributes as configurable: false,
rather configurable: true.*
If this seems reasonable, I'd like to see the spec updated.
Sorry, I'm not very updated on the differences between the ES3 and ES5 worlds. Why does
configurable: false destroyed the ability to set accessors? Can you give an
example of a piece of script that doesn't work but which you'd like to work, and what
you'd like it to do?
/ Jonas
Re: [WebIDL] interface objects and properties too restrictive?
On Aug 4, 2010, at 11:36 AM, Travis Leithead wrote:
Sure.
Not only does ES5's configurable: false property prevent deletion, but it
also prevents changing a property from a field to an accessor and vice-versa,
as well as changing the getter/setters of the property.
So, the following wouldn't work if the appendChild property was
configurable:false:
Object.defineProperty(Node.prototype,
appendChild,
{ get: function() { /* custom getter replacement */ },
set: function(x) { /* custom setter replacement */ }
});
... which is the ES5 way of doing:
Node.prototype.__defineGetter__(appendChild, function() { /* custom getter
replacement */ });
Node.prototype.__defineSetter__(appendChild, function(x) { /* custom setter
replacement */ });
So, configurable: false prevents users from replacing built-in properties
with getter/setters. I think this is too restrictive, especially
forward-looking considering how much the DOM is changing and evolving.
I don't see why you would want to do that. The common way to override the
behavior of DOM operations is:
Node.prototype.appendChild = function(node) { /* replacement function */ }
I think what you describe is not commonly done, or particularly useful.
Furthermore, prototype hacking is primarily used for additions, not
replacements, which are not impacted by this at all.
Likewise, I don't think it's common to want to add a setter for the window.Node
global interface object.
Regards,
Maciej
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, August 03, 2010 5:22 PM
To: Travis Leithead
Cc: Cameron McCormack; Sam Weinig (wei...@apple.com); public-webapps@w3.org
Subject: Re: [WebIDL] interface objects and properties too restrictive?
On Tue, Aug 3, 2010 at 4:57 PM, Travis Leithead tra...@microsoft.com wrote:
Hey folks, just wondering what the justification behind the current
{DontDelete} semantics are in WebIDL 4.4 [1] and 4.5 (second bullet)
[2]. When our IE9 binding ported this to ES5, it translated to
configurable: false, which completely destroyed the ability to set
accessors on the interface objects as well as operations (and in our
case, DOM accessors). Because of this, we actually don't mark our
interface objects OR operations/attributes as configurable: false,
rather configurable: true.*
If this seems reasonable, I'd like to see the spec updated.
Sorry, I'm not very updated on the differences between the ES3 and ES5
worlds. Why does configurable: false destroyed the ability to set
accessors? Can you give an example of a piece of script that doesn't work but
which you'd like to work, and what you'd like it to do?
/ Jonas
