[IndexedDB] Existence checking
Hi all. I have a query/suggestion regarding the current spec for IndexedDB. Currently there doesn't appear to be any specific way to check existence of things like indexes and object stores. One scenario this may be important could be a site which allows optional offline functionality, for example allowing a user to have an offline store for cars, planes and boats. The offline JavaScript code would like to query which stores were available offline. There are a couple of ways to do this: * Rely on developers to do something clever with the database version Example: bitmask what facilities are available: 1 = car, 2 = plane, 4 = boat. Database version of 3 would imply that car and plane stores were available. Comment: This may be an approach which would be recommended if the intention of the spec is for the database version to be the principle identifier of the state/version of an IndexedDB. IMHO, encouraging this method would lead to confusing database version numbers and in turn, a maintenance nightmare. * Try and catch errors Example: Attempt to open a store, catch the appropriate exception and then attempt to create the store. Comment: Code to do this is not particularly readable, and relies on invoking an error condition to find out whether a particular store exists. I'd much prefer to see a method to check for the existence of object stores/indexes that doesn't rely on try/catching exceptions. An exists check would lead to leaner, more readable code which doesn't depend on exception handling to imply the state of the database. I've not contributed here before, so please be nice if this suggestion is stupid for reasons I don't know : ) Thanks. Nathan
[cors] Allow-Credentials vs Allow-Origin: * on image elements?
Hi all-- I'm trying to understand one of the example use cases in the CORS specification and how the various rules about credentials apply, and I'm wondering whether there's an issue to resolve. In the Not tainting the canvas element example at http://dev.w3.org/2006/waf/access-control/#use-cases, it looks like the images will be requested from http://narwhalart.example using img tags. If so, it's possible the user agent will send cookies on the GET request for the images. If I understand correctly, that implies that the HTTP response would have to include Access-Control-Allow-Credentials: true, because cookies are considered credentials. However, I also see that providing Access-Control-Allow-Credentials: true means that * cannot be used for Access-Control-Allow-Origin. The use case mentions that the server could make the images accessible to all origins, though. Is the server allowed to omit the Access-Control-Allow-Credentials header and use * for Access-Control-Allow-Origin, despite the presence of cookies on the image's GET request? Also, what is the reason that * is not allowed for responses that allow credentials? I've seen it documented in several places, but I'm not sure why that's the case. In cases like images or perhaps web fonts, it seems impractical to prevent credentials from being sent (unlike XmlHttpRequests). On a similar note, are the image's GET requests required to carry Origin HTTP headers? Thanks in advance, Charlie Reis
WebIDL exceptions
Is there any agreement on how exceptions in WebIDL should map to ECMAScript objects? I can't see anything in WebIDL to specify this. I would have expected each exception type to have an interface object and an interface prototype object, both containing the constants for the exception numbers. The interface prototype objects would all inherit from the same thing (I used DOMException but ACID3 implies this is incorrect). This object would then implement toString for exceptions. Inheriting from the ECMAScript Error.prototype object would also seem reasonable. My understanding of the current browser implementation is that in Gecko and Webkit browsers the interface prototype objects have Object.prototype as their [[Prototype]]. Opera doesn't seem to have interface prototype objects for exceptions. I would propose that the right thing to say in WebIDL is that exception interface and interface prototype objects are constructed in the same manner as normal interfaces, and that the interface prototype objects have the Object.prototype object as their [[Prototype]] unless something else is indicated in the IDL. Does this seem right, or am I barking up the wrong tree? -- Andrew Oakley
Re: [IndexedDB] Existence checking
On 7/5/2010 3:19 AM, Nathan Kitchen wrote: There are a couple of ways to do this: I think you missed one. IDBDatabase has a property objectStores [1] that is an array of object stores. Additionally, IDBObjectStore has a property called indexNames [2] that is an array of indexes for the object store. We should probably look into having the same naming convention for both of those (objectStores and indexes or objectStoreNames and indexNames probably?). This accomplishes what you want, right? Cheers, Shawn [1] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabase-objectStores [2] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBObjectStore-indexNames smime.p7s Description: S/MIME Cryptographic Signature
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/2010 12:36 PM, Jonas Sicking wrote: On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro pablo.cas...@microsoft.com wrote: We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. / Jonas It sounds like returning to delete() for deleting records from a store is agreeable. Can the spec be updated or are we still sticking with remove()? - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK 6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb =lG0c -END PGP SIGNATURE-
Re: [IndexedDB] Cursors and modifications
On Sat, Jul 3, 2010 at 2:09 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jul 2, 2010 at 5:44 PM, Andrei Popescu andr...@google.com wrote:
On Sat, Jul 3, 2010 at 1:14 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jul 2, 2010 at 4:40 PM, Pablo Castro pablo.cas...@microsoft.com
wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of Jonas Sicking
Sent: Friday, July 02, 2010 4:00 PM
We ran into an complicated issue while implementing IndexedDB. In short,
what should happen if an object store is modified while a cursor is
iterating it? Note that the modification can be done within the same
transaction, so the read/write locks preventing several transactions
from accessing the same table isn't helping here.
Detailed problem description (this assumes the API proposed by mozilla):
Consider a objectStore words containing the following objects:
{ name: alpha }
{ name: bravo }
{ name: charlie }
{ name: delta }
and the following program (db is a previously opened IDBDatabase):
var trans = db.transaction([words], READ_WRITE); var cursor; var
result = []; trans.objectStore(words).openCursor().onsuccess =
function(e) {
cursor = e.result;
result.push(cursor.value);
cursor.continue();
}
trans.objectStore(words).get(delta).onsuccess = function(e) {
trans.objectStore(words).put({ name: delta, myModifiedValue: 17
}); }
When the cursor reads the delta entry, will it see the
'myModifiedValue' property? Since we so far has defined that the
callback order is defined to be the request order, that means that
put request will be finished before the delta entry is iterated by the
cursor.
The problem is even more serious with cursors that iterate indexes.
Here a modification can even affect the position of the currently
iterated object in the index, and the modification can (if i'm reading
the spec correctly) come from the cursor itself.
Consider the following objectStore people with keyPath name
containing the following objects:
{ name: Adam, count: 30 }
{ name: Bertil, count: 31 }
{ name: Cesar, count: 32 }
{ name: David, count: 33 }
{ name: Erik, count: 35 }
and an index countIndex with keyPath count. What would the following
code do?
results = [];
db.objectStore(people,
READ_WRITE).index(countIndex).openObjectCursor().onsuccess = function
(e) {
cursor = e.result;
if (!cursor) {
alert(results);
return;
}
if (cursor.value.name == Bertil) {
cursor.update({name: Bertil, count: 34 });
}
results.push(cursor.value.name);
cursor.continue();
};
What does this alert? Would it alert Adam,Bertil,Erik as the cursor
would stay on the Bertil object as it is moved in the index? Or would
it alert Adam,Bertil,Cesar,David,Bertil,Erik as we would iterate
Bertil again at its new position in the index?
My first reaction is that both from the expected behavior of perspective
(transaction is the scope of isolation) and from the implementation
perspective it would be better to see live changes if they happened in the
same transaction as the cursor (over a store or index). So in your example
you would iterate one of the rows twice. Maintaining order and membership
stable would mean creating another scope of isolation within the
transaction, which to me would be unusual and it would be probably quite
painful to implement without spilling a copy of the records to disk (at
least a copy of the keys/order if you don't care about protecting from
changes that don't affect membership/order; some databases call these
keyset cursors).
We could say that cursors always iterate snapshots, however this
introduces MVCC. Though it seems to me that SNAPSHOT_READ already does
that.
Actually, even with MVCC you'd see your own changes, because they happen
in the same transaction so the buffer pool will use the same version of
the page. While it may be possible to reuse the MVCC infrastructure, it
would still require the introduction of a second scope for stability.
It's quite implementable using append-only b-trees. Though it might be
much to ask that implementations are forced to use that.
An alternative to what I suggested earlier is that all read operations
use read committed. I.e. they always see the data as it looked at
the beginning of the transaction. Would this be more compatible with
existing MVCC implementations?
Hmm, so if you modified the object store and then, later in the same
transaction, used a cursor to iterate the object store, the cursor
would not see the earlier modifications? That's not very intiutive to
me...or did I misunderstand?
If we go with read committed then yes, your understanding is correct.
Out of curiosity, how are you feeling about the cursors iterate data
as it looked when cursor was opened solution?
I feel that that's the easiest solution to specify although it may
also be unintuitive if one calls 'put
Re: [IndexedDB] Should .add/.put/.update throw when called in read-only transaction?
On Sat, Jul 3, 2010 at 1:52 AM, Andrei Popescu andr...@google.com wrote: On Fri, Jul 2, 2010 at 9:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 2, 2010 at 1:02 PM, Andrei Popescu andr...@google.com wrote: On Fri, Jul 2, 2010 at 10:43 AM, Jonas Sicking jo...@sicking.cc wrote: Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10064 Fixed. Please have a look, in case I missed or got anything wrong. Thanks! For add and put you should not throw DATA_ERR if the objectStore has a key generator. Oh, I thought I added a sentence about that. Will fix on Monday. Fixed. Andrei
[Bug 10088] New: The spec does not define what happens if an object store is modified while a cursor is iterating it.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10088 Summary: The spec does not define what happens if an object store is modified while a cursor is iterating it. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: andr...@google.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org It is possible to modify an object store while a cursor is iterating over its objects in the same transaction. Right now, the behavior of the cursor is unspecified. We discussed the 3 solutions for handling this situation: 1. Making the cursor iterate over a snapshot of the data, that is, modifications done during the iteration are not visible when the cursor callbacks fire. The snapshot would be taken when the cursor is created. 2. As 1, except that the snapshot is taken when the transaction starts. 3. Cursors iterate over live data and modifications to the object store are visible during the iteration. The consensus for now is to go with solution 3. For pros and cons of each approach as well as motivation for picking the current solution, please see: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0056.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] Existence checking
That would do the trick, yes. Thanks for pointing it out, all my w3 spec reading skills are belong to you. On Mon, Jul 5, 2010 at 4:44 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 7/5/2010 3:19 AM, Nathan Kitchen wrote: There are a couple of ways to do this: I think you missed one. IDBDatabase has a property objectStores [1] that is an array of object stores. Additionally, IDBObjectStore has a property called indexNames [2] that is an array of indexes for the object store. We should probably look into having the same naming convention for both of those (objectStores and indexes or objectStoreNames and indexNames probably?). This accomplishes what you want, right? Cheers, Shawn [1] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBDatabase-objectStores [2] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBObjectStore-indexNames
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
There seems to be agreement that delete() is acceptable. Could you file a bug? / Jonas On Monday, July 5, 2010, Kris Zyp k...@sitepen.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/2010 12:36 PM, Jonas Sicking wrote: On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro pablo.cas...@microsoft.com pablo.cas...@microsoft.com wrote: We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. / Jonas It sounds like returning to delete() for deleting records from a store is agreeable. Can the spec be updated or are we still sticking with remove()? - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK 6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb =lG0c -END PGP SIGNATURE-
