Re: Obsolescence notices on old specifications, again
Hello, since when is obsolete the same as work in progress? How does HTML4 (can be considered obsolete) the same as HTML5(in progress)? It only means that new features are added to HTML5 not to HTML 4 and any error in HTML 4 is ignored... This discussion is about using word obsolete in simple sentence, that is clear to developers or usage of language that would be more comfortable to politicians and high management, some complicated sentence, that is more politically correct. Again the question is: should we care? Should W3C creates new mechanism to reflect current speed of progress instead of bound progress by decade and 1/2 old processes? Should W3C creates some guidelines for understanding current state of work for external entities, that those have to understand that specs can become obsolete, that people can be explicitly discouraged from implementing them and is can happen anytime to any spec without any control of such external entities? On 24.1.2012 20:33, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. 2012/1/24 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona Brona
Re: Obsolescence notices on old specifications, again
Hello Just to be perfectly clear here... I do not think we should phrase document statuses according to some external needs, because in this case we may end up with phrasing fitting Glenns needs, but it may not be fitting other legislatures or other companies internal needs and then what? Brona On 25.1.2012 10:10, Bronislav Klučka wrote: Hello, since when is obsolete the same as work in progress? How does HTML4 (can be considered obsolete) the same as HTML5(in progress)? It only means that new features are added to HTML5 not to HTML 4 and any error in HTML 4 is ignored... This discussion is about using word obsolete in simple sentence, that is clear to developers or usage of language that would be more comfortable to politicians and high management, some complicated sentence, that is more politically correct. Again the question is: should we care? Should W3C creates new mechanism to reflect current speed of progress instead of bound progress by decade and 1/2 old processes? Should W3C creates some guidelines for understanding current state of work for external entities, that those have to understand that specs can become obsolete, that people can be explicitly discouraged from implementing them and is can happen anytime to any spec without any control of such external entities? On 24.1.2012 20:33, Glenn Adams wrote: The problem is that the proposal (as I understand it) is to insert something like: DOM2 (a REC) is obsolete. Use DOM4 (a work in progress). This addition is tantamount (by the reading of some) to demoting the status of DOM2 to a work in progress. 2012/1/24 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com Hello, I do understand the objection, but how relevant should it be here? If some regulation/law dictates that work must follow e.g. DOM 2, than it does not matter that it's obsolete... The law takes precedence here regardless of status of the document. Technically in such case one don't need to worry himself about any progress or status of such document or specification. On 23.1.2012 19:06, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. Brona Brona
Re: [indexeddb] Do we need to support keyPaths with an empty string?
On Tue, Jan 24, 2012 at 12:07 PM, Israel Hilerio isra...@microsoft.com wrote:
On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com
wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm
here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-step
s-f or-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to continue to allow set behavior without specifying the
key twice, though, so we would propose adding an additional option
to createObjectStore to accomplish this:
// Old way:
var set = db.createObjectStore(mySet, { keyPath: });
set.put(keyValue);
// New way:
var set = db.createObjectStore(mySet, { isSet: true });
set.put(keyValue);
(We are not in love with isSet, better names are highly
encouraged!)
What do you all think? This would allow us to continue to support
nice set behavior without making the empty string magic.
I actually think that the current behavior that we have is pretty
consistent. Any time you give the keyPath property a string we create
an objectStore with a keyPath. And any time you have an objectStore
with a keyPath you are not allowed to pass an explicit key since the
key is gotten from the keyPath. There's no special handling of empty
strings happening.
But I do agree that it can be somewhat confusing to tell
/null/undefined apart since they are all falsy. In particular, an
expression like
if (myObjectStore.keyPath) {
...
}
doesn't work to test if an objectStore has a keyPath or not. You
instead need to check
if (myObjectStore.keyPath != null) {
...
}
or
if (typeof myObjectStore.keyPath == string) {
...
}
Hence the isSet suggestion.
Though I also realized after talking to Ben that empty keyPaths show
up in indexes too. Consider creating a objectStore which maps peoples
names to email addresses. Then you can create an index when does the
opposite mapping, or which ensures that email addresses are unique:
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, , { unique: true });
store.add(john@email.com, John Doe);
store.add(m...@smith.org, Mike Smith);
store.get(John Doe).onsuccess = function(e) {
alert(John's email is + e.target.result); }
index.getKey(m...@smith.org).onsuccess = function(e) {
alert(m...@smith.org is owned by + e.target.result); }
Are people proposing we remove empty keyPaths here too?
/ Jonas
Yes, I'm proposing removing empty string KeyPaths all together to avoid
confusion.
I would like to know how often you expect developers to follow this
pattern instead of using objects. Our believe is that objects will be
the main value stored in object stores instead of single values.
Supporting keyPath with empty strings brings up all kinds of side effects.
For example:
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, , { unique: true });
store.add({email: john@email.com}, John Doe);
store.add({email: m...@smith.org},Mike Smith);
What should happen in this case, do we throw an exception?
This doesn't seem any different from
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, x, { unique: true }); store.add({ x: {email:
john@email.com} }, John Doe); store.add({ x: {email:
m...@smith.org} },Mike Smith);
IIRC we decided a while ago that indexes do not add constraints. I.e.
that if the keyPath for an index doesn't yield a valid key, then the index
simply doesn't get an entry pointing to newly stored value.
So I don't really see that empty keyPaths bring up any special cases.
The only special case we have in Firefox for empty keyPaths (apart from the
keyPath evaluation code itself) is the code that throws an exception if you
try
to create an objectStore with an empty keyPath and a key generator.
Having some type of flag seems more promising for object stores.
However, we still need to figure out how to deal with Indexes on sets, do
we pass another flag to support the indexes on sets? If we do that, then
what do we do with the keyPath parameter to an index.
It seems we're overloading the functionality of these methods to support
different patterns.
Indeed, supporting the same use cases but using something other than
empty key paths gets pretty messy for indexes. If we want to keep supporting
these use cases (which I personally do), then I think using empty key paths
is
the cleanest solution.
Really the only downside that I see is the somewhat non-intuitive
objectStore.keyPath != null check. But
Re: Obsolescence notices on old specifications, again
Hi All - I just chatted with Ms2ger in IRC about his proposal [1]. Ms2ger will submit proposed text to the list so we should probably hold off on additional comments until we get that proposal. (I agree rescinding is not what we want to do for these specs.) -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0245.html On 1/24/12 7:26 AM, ext Charles McCathieNevile wrote: On Tue, 24 Jan 2012 11:02:55 +0100, Ms2ger ms2...@gmail.com wrote: On 01/24/2012 01:58 AM, Bjoern Hoehrmann wrote: * Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I should have been clearer; this is indeed all I intend to say. OK, this looks like the sort of message that Opera would support. As Art said, I think we need individual proposals per spec. And I am not sure that rescinding specs we don't like much is necessarily a good idea. cheers
Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Tue, Jan 24, 2012 at 11:38 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
What happens if a value higher up in the keyPath is not an object:
store = db.createObjectStore(os, { keyPath: a.b.c, autoIncrement:
true
});
store.put({ a: str });
Here there not only is nowhere to directly store the new value. We
also can't simply insert the missing objects since we can't add a b
property to the value str. Exact same scenario appears if you
replace str with a 1 or null.
What we do in Firefox is to throw a DataError exception.
Another example of this is simply
store = db.createObjectStore(os, { keyPath: a, autoIncrement: true
});
store.put(str);
Chrome currently defers setting the new value until the transaction
executes
the asynchronous request, and thus doesn't raise an exception but fails
the
request. I agree that doing this at the time of the call makes more sense
and is more consistent and predictable. If there's consensus here I'll
file
a bug against Chromium.
Awesome!
One clarification here: I believe the key generation logic must run as part
of the asynchronous storage operation within the request so the key
generator state is contained within the transaction (i.e. an aborted
transaction would reset the key generator state for stores in scope).
Therefore inserting the key into the value must still wait until the
request is processed. That implies that at call time the value should be
checked to ensure the generated key can be inserted, and then at storage
operation time the value is actually updated.
Does this match others' interpretation?
Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
On Wed, Jan 25, 2012 at 11:38 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 11:38 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
What happens if a value higher up in the keyPath is not an object:
store = db.createObjectStore(os, { keyPath: a.b.c, autoIncrement:
true
});
store.put({ a: str });
Here there not only is nowhere to directly store the new value. We
also can't simply insert the missing objects since we can't add a b
property to the value str. Exact same scenario appears if you
replace str with a 1 or null.
What we do in Firefox is to throw a DataError exception.
Another example of this is simply
store = db.createObjectStore(os, { keyPath: a, autoIncrement: true
});
store.put(str);
Chrome currently defers setting the new value until the transaction
executes
the asynchronous request, and thus doesn't raise an exception but fails
the
request. I agree that doing this at the time of the call makes more
sense
and is more consistent and predictable. If there's consensus here I'll
file
a bug against Chromium.
Awesome!
One clarification here: I believe the key generation logic must run as part
of the asynchronous storage operation within the request so the key
generator state is contained within the transaction (i.e. an aborted
transaction would reset the key generator state for stores in scope).
Therefore inserting the key into the value must still wait until the request
is processed. That implies that at call time the value should be checked to
ensure the generated key can be inserted, and then at storage operation time
the value is actually updated.
Does this match others' interpretation?
Conceptually I agree. In Firefox we do use a different approach
though. We actually insert a dummy value synchronously and then
serialize and send off to the database thread. But when we serialize
we do that in such a way that we know where in the serialization the
dummy-value resides. That way the database thread can update the value
to write the generated key into the serialized value.
But the generated key is definitely generated on the database-thread
at least in the general case.
This does bring up another thing that is undefined though, which is
the specifics of key generation. I'll start a separate thread on that.
/ Jonas
[IndexedDB] Key generation details
Hi All,
Joshua reminded me of another thing which is undefined in the
specification, which is key generation. Here's the details of how we
do it in Firefox:
The key generator for each objectStore starts at 1 and is increased by
1 every time a new key is generated.
Each objectStore has its own key generator. See comments for the
following code example:
store1 = db.createObjectStore(store1, { autoIncrement: true });
store1.put(a); // Will get key 1
store2 = db.createObjectStore(store2, { autoIncrement: true });
store2.put(a); // Will get key 1
store1.put(b); // Will get key 2
store2.put(b); // Will get key 2
If an insertion fails due to constraint violations or IO error, the
key generator is not updated.
trans.onerror = function(e) { e.preventDefault() };
store = db.createObjectStore(store1, { autoIncrement: true });
index = store.createIndex(index1, ix, { unique: true });
store.put({ ix: a}); // Will get key 1
store.put({ ix: a}); // Will fail
store.put({ ix: b}); // Will get key 2
Removing items from an objectStore never affects the key generator.
Including when .clear() is called.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1
store.delete(1);
store.put(b); // Will get key 2
store.clear();
store.put(c); // Will get key 3
store.delete(IDBKeyRange.lowerBound(0));
store.put(d); // Will get key 4
Inserting an item with an explicit key affects the key generator if,
and only if, the key is numeric and higher than the last generated
key.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1
store.put(b, 3); // Will use key 3
store.put(c); // Will get key 4
store.put(d, -10); // Will use key -10
store.put(e); // Will get key 5
store.put(f, 6.1); // Will use key 6.0001
store.put(g); // Will get key 7
store.put(f, 8.); // Will use key 8.
store.put(g); // Will get key 9
store.put(h, foo); // Will use key foo
store.put(i); // Will get key 10
store.put(j, [1000]); // Will use key [1000]
store.put(k); // Will get key 11
// All of these would behave the same if the objectStore used a
keyPath and the explicit key was passed inline in the object
Aborting a transaction rolls back any increases to the key generator
which happened during the transaction. This is to make all rollbacks
consistent since rollbacks that happen due to crash never has a chance
to commit the increased key generator value.
db.createObjectStore(store, { autoIncrement: true });
...
trans1 = db.transaction([store]);
store_t1 = trans1.objectStore(store);
store_t1.put(a); // Will get key 1
store_t1.put(b); // Will get key 2
trans1.abort();
trans2 = db.transaction([store]);
store_t2 = trans2.objectStore(store);
store_t2.put(c); // Will get key 1
store_t2.put(d); // Will get key 2
/ Jonas
RE: [indexeddb] Do we need to support keyPaths with an empty string?
On Wednesday, January 25, 2012 1:47 AM, Jonas Sicking wrote:
On Tue, Jan 24, 2012 at 12:07 PM, Israel Hilerio
isra...@microsoft.com
wrote:
On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio
isra...@microsoft.com
wrote:
On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 12:23 PM, ben turner
bent.mozi...@gmail.com
wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the
algorithm here
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn
-s tep s-f or-extracting-a-key-from-a-value-using-a-key-path
will need to change.
We do want to continue to allow set behavior without
specifying the key twice, though, so we would propose adding
an additional option to createObjectStore to accomplish this:
// Old way:
var set = db.createObjectStore(mySet, { keyPath: });
set.put(keyValue);
// New way:
var set = db.createObjectStore(mySet, { isSet: true });
set.put(keyValue);
(We are not in love with isSet, better names are highly
encouraged!)
What do you all think? This would allow us to continue to
support nice set behavior without making the empty string magic.
I actually think that the current behavior that we have is
pretty consistent. Any time you give the keyPath property a
string we create an objectStore with a keyPath. And any time you
have an objectStore with a keyPath you are not allowed to pass
an explicit key since the key is gotten from the keyPath.
There's no special handling of empty
strings happening.
But I do agree that it can be somewhat confusing to tell
/null/undefined apart since they are all falsy. In particular,
an expression like
if (myObjectStore.keyPath) {
...
}
doesn't work to test if an objectStore has a keyPath or not. You
instead need to check
if (myObjectStore.keyPath != null) {
...
}
or
if (typeof myObjectStore.keyPath == string) {
...
}
Hence the isSet suggestion.
Though I also realized after talking to Ben that empty keyPaths
show up in indexes too. Consider creating a objectStore which
maps peoples names to email addresses. Then you can create an
index when does the opposite mapping, or which ensures that
email
addresses are unique:
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, , { unique: true });
store.add(john@email.com, John Doe);
store.add(m...@smith.org, Mike Smith);
store.get(John Doe).onsuccess = function(e) {
alert(John's email is + e.target.result); }
index.getKey(m...@smith.org).onsuccess = function(e) {
alert(m...@smith.org is owned by + e.target.result); }
Are people proposing we remove empty keyPaths here too?
/ Jonas
Yes, I'm proposing removing empty string KeyPaths all together to
avoid
confusion.
I would like to know how often you expect developers to follow
this pattern instead of using objects. Our believe is that
objects will be the main value stored in object stores instead of single
values.
Supporting keyPath with empty strings brings up all kinds of side
effects.
For example:
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, , { unique: true });
store.add({email: john@email.com}, John Doe);
store.add({email: m...@smith.org},Mike Smith);
What should happen in this case, do we throw an exception?
This doesn't seem any different from
var store = db.createObjectStore(people); var index =
store.createIndex(reverse, x, { unique: true }); store.add({ x: {email:
john@email.com} }, John Doe); store.add({ x: {email:
m...@smith.org} },Mike Smith);
IIRC we decided a while ago that indexes do not add constraints. I.e.
that if the keyPath for an index doesn't yield a valid key, then
the index simply doesn't get an entry pointing to newly stored value.
So I don't really see that empty keyPaths bring up any special cases.
The only special case we have in Firefox for empty keyPaths (apart
from the keyPath evaluation code itself) is the code that throws an
exception if you try to create an objectStore with an empty keyPath
and a
key generator.
Having some type of flag seems more promising for object stores.
However, we still need to figure out how to deal with Indexes on
sets, do
we pass another flag to support the indexes on sets? If we do
that, then what do we do with the keyPath parameter to an index.
It seems we're overloading the functionality of these methods to
support
different patterns.
Indeed, supporting the same use cases but using something other
than empty key paths gets pretty messy
RE: [IndexedDB] Key generation details
On Wednesday, January 25, 2012 12:25 PM, Jonas Sicking wrote:
Hi All,
Joshua reminded me of another thing which is undefined in the specification,
which is key generation. Here's the details of how we do it in Firefox:
The key generator for each objectStore starts at 1 and is increased by
1 every time a new key is generated.
Each objectStore has its own key generator. See comments for the following
code example:
store1 = db.createObjectStore(store1, { autoIncrement: true });
store1.put(a); // Will get key 1
store2 = db.createObjectStore(store2, { autoIncrement: true });
store2.put(a); // Will get key 1 store1.put(b); // Will get key 2
store2.put(b); // Will get key 2
If an insertion fails due to constraint violations or IO error, the key
generator
is not updated.
trans.onerror = function(e) { e.preventDefault() }; store =
db.createObjectStore(store1, { autoIncrement: true }); index =
store.createIndex(index1, ix, { unique: true }); store.put({ ix: a});
// Will
get key 1 store.put({ ix: a}); // Will fail store.put({ ix: b}); // Will
get key 2
Removing items from an objectStore never affects the key generator.
Including when .clear() is called.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1 store.delete(1); store.put(b); // Will
get key
2 store.clear(); store.put(c); // Will get key 3
store.delete(IDBKeyRange.lowerBound(0));
store.put(d); // Will get key 4
Inserting an item with an explicit key affects the key generator if, and only
if,
the key is numeric and higher than the last generated key.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1 store.put(b, 3); // Will use key 3
store.put(c); // Will get key 4 store.put(d, -10); // Will use key -10
store.put(e); // Will get key 5 store.put(f, 6.1); // Will use key
6.0001
store.put(g); // Will get key 7 store.put(f, 8.); // Will use key
8.
store.put(g); // Will get key 9 store.put(h, foo); // Will use key foo
store.put(i); // Will get key 10
store.put(j, [1000]); // Will use key [1000] store.put(k); // Will get
key 11
// All of these would behave the same if the objectStore used a keyPath and
the explicit key was passed inline in the object
Aborting a transaction rolls back any increases to the key generator which
happened during the transaction. This is to make all rollbacks consistent
since rollbacks that happen due to crash never has a chance to commit the
increased key generator value.
db.createObjectStore(store, { autoIncrement: true }); ...
trans1 = db.transaction([store]);
store_t1 = trans1.objectStore(store);
store_t1.put(a); // Will get key 1
store_t1.put(b); // Will get key 2
trans1.abort();
trans2 = db.transaction([store]);
store_t2 = trans2.objectStore(store);
store_t2.put(c); // Will get key 1
store_t2.put(d); // Will get key 2
/ Jonas
IE follows the same behavior, as FF, for all of these scenarios.
Israel
[indexeddb] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction
Should we allow the creation of READ_ONLY or READ_WRITE transactions inside the oncomplete event handler of a VERSION_CHANGE transaction? IE allows this behavior today. However, we noticed that FF's nightly doesn't. In either case, we should define this behavior in the spec. Israel
[Bug 15717] New: Adding TransactionInactiveError to IDBObjectStore.count and IDBIndex.count
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15717 Summary: Adding TransactionInactiveError to IDBObjectStore.count and IDBIndex.count Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: isra...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Per this WG email thread: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0262.html We agree to add TransactionInactiveError to the following two methods: * IDBObjectStore.count * IDBIndex.count Israel -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15719] New: Under section Disk Space, there seems to be a word missing in the sentence (see part in parens): User agents should guard against sites storing data (under the origins other affi
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15719 Summary: Under section Disk Space, there seems to be a word missing in the sentence (see part in parens): User agents should guard against sites storing data (under the origins other affiliated sites) Should it have said under the origins _of_ other affiliate Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Under section Disk Space, there seems to be a word missing in the sentence (see part in parens): User agents should guard against sites storing data (under the origins other affiliated sites) Should it have said under the origins _of_ other affiliated sites? Posted from: 12.158.89.31 User agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 -- Configure bugmail: https://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] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction
On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio isra...@microsoft.com wrote: Should we allow the creation of READ_ONLY or READ_WRITE transactions inside the oncomplete event handler of a VERSION_CHANGE transaction? IE allows this behavior today. However, we noticed that FF's nightly doesn't. Yeah, it'd make sense to me to allow this. In either case, we should define this behavior in the spec. Agreed. I can't even find anything in the spec that says that calling the transaction() function should fail if you call it while the VERSION_CHANGE transaction is still running. I think we should spec that if transaction() is called before either the VERSION_CHANGE transaction is committed (i.e. the complete event has *started* firing), or the success event has *started* firing on the IDBRequest returned from .open, we should throw a InvalidStateError. Does this sound good? / Jonas
Re: [IndexedDB] Key generation details
On Wed, Jan 25, 2012 at 3:05 PM, Israel Hilerio isra...@microsoft.comwrote:
On Wednesday, January 25, 2012 12:25 PM, Jonas Sicking wrote:
Hi All,
Joshua reminded me of another thing which is undefined in the
specification,
which is key generation. Here's the details of how we do it in Firefox:
The key generator for each objectStore starts at 1 and is increased by
1 every time a new key is generated.
Each objectStore has its own key generator. See comments for the
following
code example:
store1 = db.createObjectStore(store1, { autoIncrement: true });
store1.put(a); // Will get key 1
store2 = db.createObjectStore(store2, { autoIncrement: true });
store2.put(a); // Will get key 1 store1.put(b); // Will get key 2
store2.put(b); // Will get key 2
If an insertion fails due to constraint violations or IO error, the key
generator
is not updated.
trans.onerror = function(e) { e.preventDefault() }; store =
db.createObjectStore(store1, { autoIncrement: true }); index =
store.createIndex(index1, ix, { unique: true }); store.put({ ix:
a}); // Will
get key 1 store.put({ ix: a}); // Will fail store.put({ ix: b}); //
Will get key 2
Removing items from an objectStore never affects the key generator.
Including when .clear() is called.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1 store.delete(1); store.put(b); //
Will get key
2 store.clear(); store.put(c); // Will get key 3
store.delete(IDBKeyRange.lowerBound(0));
store.put(d); // Will get key 4
Inserting an item with an explicit key affects the key generator if, and
only if,
the key is numeric and higher than the last generated key.
store = db.createObjectStore(store1, { autoIncrement: true });
store.put(a); // Will get key 1 store.put(b, 3); // Will use key 3
store.put(c); // Will get key 4 store.put(d, -10); // Will use key
-10
store.put(e); // Will get key 5 store.put(f, 6.1); // Will use
key 6.0001
store.put(g); // Will get key 7 store.put(f, 8.); // Will use
key 8.
store.put(g); // Will get key 9 store.put(h, foo); // Will use key
foo
store.put(i); // Will get key 10
store.put(j, [1000]); // Will use key [1000] store.put(k); // Will
get key 11
// All of these would behave the same if the objectStore used a keyPath
and
the explicit key was passed inline in the object
Aborting a transaction rolls back any increases to the key generator
which
happened during the transaction. This is to make all rollbacks consistent
since rollbacks that happen due to crash never has a chance to commit the
increased key generator value.
db.createObjectStore(store, { autoIncrement: true }); ...
trans1 = db.transaction([store]);
store_t1 = trans1.objectStore(store);
store_t1.put(a); // Will get key 1
store_t1.put(b); // Will get key 2
trans1.abort();
trans2 = db.transaction([store]);
store_t2 = trans2.objectStore(store);
store_t2.put(c); // Will get key 1
store_t2.put(d); // Will get key 2
/ Jonas
IE follows the same behavior, as FF, for all of these scenarios.
Israel
This is the behavior I'd expect, but it looks like Chromium currently
deviates from this in a few cases. I'll dig in further to see if the issue
is in Chromium or my test code.
[Bug 15721] New: [IndexedDB] Specify when calling transaction() should throw due to being called too early
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15721 Summary: [IndexedDB] Specify when calling transaction() should throw due to being called too early Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specifically Firefox appears to throw before the onsuccess event is fired on the IDBRequest returned from .open. IE however allows it to be called as soon as the oncomplete event is fired on the VERSION_CHANGE transaction. The IE behavior seems like the better one to me. Currently transaction() doesn't appear to throw due to being called too early in the spec at all. -- Configure bugmail: https://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] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction
On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote: On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio isra...@microsoft.com wrote: Should we allow the creation of READ_ONLY or READ_WRITE transactions inside the oncomplete event handler of a VERSION_CHANGE transaction? IE allows this behavior today. However, we noticed that FF's nightly doesn't. Yeah, it'd make sense to me to allow this. In either case, we should define this behavior in the spec. Agreed. I can't even find anything in the spec that says that calling the transaction() function should fail if you call it while the VERSION_CHANGE transaction is still running. I think we should spec that if transaction() is called before either the VERSION_CHANGE transaction is committed (i.e. the complete event has *started* firing), or the success event has *started* firing on the IDBRequest returned from .open, we should throw a InvalidStateError. Does this sound good? / Jonas Just to make sure we understood you correctly! We looked again at the spec and noticed that the IDBDatabase.transaction method says the following: * This method must throw a DOMException of type InvalidStateError if called before the success event for an open call has been dispatched. This implies that we're not allowed to open a new transaction inside the oncomplete event handler of the VERSION_CHANGE transaction. From your statement above, it seems you agree with IE's behavior which negates this statement. That implies we'll need to remove this line from the spec. Also, we'll have to remove the last part of your proposed statement to something like: If the transaction method is called before the VERSION_CHANGE transaction is committed (i.e. the complete event has *started* firing), we should throw an InvalidStateError exception. Otherwise, the method returns an IDBTransaction object representing the transaction returned by the steps above. Israel
Re: [indexeddb] Creating transactions inside the oncomplete handler of a VERSION_CHANGE transaction
On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote: On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio isra...@microsoft.com wrote: Should we allow the creation of READ_ONLY or READ_WRITE transactions inside the oncomplete event handler of a VERSION_CHANGE transaction? IE allows this behavior today. However, we noticed that FF's nightly doesn't. Yeah, it'd make sense to me to allow this. In either case, we should define this behavior in the spec. Agreed. I can't even find anything in the spec that says that calling the transaction() function should fail if you call it while the VERSION_CHANGE transaction is still running. I think we should spec that if transaction() is called before either the VERSION_CHANGE transaction is committed (i.e. the complete event has *started* firing), or the success event has *started* firing on the IDBRequest returned from .open, we should throw a InvalidStateError. Does this sound good? / Jonas Just to make sure we understood you correctly! We looked again at the spec and noticed that the IDBDatabase.transaction method says the following: * This method must throw a DOMException of type InvalidStateError if called before the success event for an open call has been dispatched. Ah! There it is! I thought we had something but couldn't find it as I was just looking at the exception table. That explains Firefox behavior then. This implies that we're not allowed to open a new transaction inside the oncomplete event handler of the VERSION_CHANGE transaction. From your statement above, it seems you agree with IE's behavior which negates this statement. Yup. Though given that the spec does in fact explicitly state a behavior we should also get an ok from Google to change that behavior. That implies we'll need to remove this line from the spec. Well.. I'd say we need to change it rather than remove it. Also, we'll have to remove the last part of your proposed statement to something like: If the transaction method is called before the VERSION_CHANGE transaction is committed (i.e. the complete event has *started* firing), we should throw an InvalidStateError exception. Otherwise, the method returns an IDBTransaction object representing the transaction returned by the steps above. We also need to say something about the situation when no VERSION_CHANGE transaction is run at all though. That's why I had the other part of the statement. / Jonas
