- From: <bugzilla@jessica.w3.org>
- Date: Mon, 13 Aug 2012 22:00:46 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551
Joshua Bell <jsbell@chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsbell@chromium.org
--- Comment #1 from Joshua Bell <jsbell@chromium.org> 2012-08-13 22:00:46 UTC ---
How precise do we need to be in terms of when the constraint enforcement will
begin? Just to throw out one more example:
request1 = store.put({name: 'carol'}, 1);
store.createIndex('index', 'name', {unique: true});
request2 = store.put({name: 'carol'}, 2);
If the timing of the index population/constraint enforcement is not defined,
what happens here remains ambiguous:
index metadata updated
process request1 -> success
index population here?? -> no abort
process request2 -> constraint error??
or index population here?? -> abort
Depending on when the index is populated / constraint is enforced, the second
request could succeed or fail.
It sounds like at least some implementations (WebKit, Gecko) treat the index
population like a request internally, and therefore in the third example the
second request would indeed be processed after the population and fail with a
(preventable) constraint error. We probably need to be precise, e.g. reference
the "steps for asynchronously executing a request" so that the "Wait until all
previously added requests in transaction have their done flag set to true"
clause is invoked.
...
The timing of deleteIndex() may also need to be clarified. E.g. what is the
behavior of:
store.createIndex('index', 'name', {unique: true});
request1 = store.put({name: 'bob'}, 1);
request2 = store.put({name: 'bob'}, 2);
store.deleteIndex('index');
One possible interpretation:
index metadata added
index metadata removed
index population (skipped)
process request1 -> success
process request2 -> success
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 13 August 2012 22:00:49 UTC