Re: [IndexedDB] Current editor's draft
On Fri, Jul 9, 2010 at 12:21 PM, Nikunj Mehta wrote: >>> >>> I don't think it's even possible with the current API since >>> openTransaction() takes a list of objectStore names but a single mode. >> >> Indeed. We could allow static transactions to use different lock >> levels for different objectStores, all specified when the >> IDBTransaction is initially created. It's just a matter of syntax to >> the IDBDatabase.transaction() function. However so far I've thought >> that we should leave this for v2. But if people would feel more easy >> about dropping dynamic transactions if we add this ability, then I >> would be ok with it. > > From my examples, it was clear that we need different object stores to be > opened in different modes. Currently dynamic scope supports this use case, > i.e., allow mode specification on a per object-store basis. Therefore, unless > we decide to de-support this use case, we would need to add this ability to > static scope transactions if dynamic scope transactions go out of v1. I don't see why you couldn't always open all needed objectStores in READ_WRITE mode? Can you point to the specific function where this wouldn't be possible? If it is the case that specifying a mode when opening an objectStore only makes sense on dynamic transactions, then I think we should only expose that argument on dynamic transactions. Now that I understand your proposal better, I don't understand how IDBTransaction.objectStore works for dynamically scoped transactions in your proposal. It seems to require synchronously grabbing a lock which I thought we wanted to avoid at all cost. > > See below. > >>> >>> This is rather confusing: is IDBTransaction::objectStore() creating an >>> object store, now? If yes, then it must lock it synchronously. If it just >>> returns an object store that was previously added to the transaction, what >>> is the 'mode' parameter for? >> >> Looking at Nikunj's example code, it seems like you can request a new >> objectStore to be locked using IDBTransaction.objectStore(). Not sure >> if that is a bug or not though? > > That was a bug. For dynamic transactions, obtaining an object store would > have to be asynchronous as it involves obtaining a lock. Ok, so what happens if IDBTransaction.objectStore is called during a dynamic transaction? Or if IDBDatabase.openObjectStore is called from a static transaction? What if IDBDatabase.openObjectStore is called from a static transaction using a objectStore name which wasn't locked when the transaction was created? I really think we need to separate the interfaces for dynamic and static transactions and have the synchronous .objectStore only available on static transactions, while the asynchronous .openObjectStore needs to be available only on dynamic transactions. > I also did not hear from you about explicit commits. Did that mean that you > agree with that part of my proposal? There are several examples where it > makes sense to explicitly commit, although it is automatic in some cases. I haven't yet had time to analyze this. I wanted to do so before commenting. I don't have time right now, but will do so tomorrow. / Jonas
Re: [IndexedDB] Current editor's draft
On Fri, Jul 9, 2010 at 11:44 AM, Nikunj Mehta wrote: > > On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote: > >> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote: >>> >>> >>> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote: On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote: > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote: >> >> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta >> wrote: >>> Hi folks, >>> >>> There are several unimplemented proposals on strengthening and >>> expanding IndexedDB. The reason I have not implemented them yet is >>> because I am not convinced they are necessary in toto. Here's my >>> attempt at explaining why. I apologize in advance for not responding >>> to individual proposals due to personal time constraints. I will >>> however respond in detail on individual bug reports, e.g., as I did >>> with 9975. >>> >>> I used the current editor's draft asynchronous API to understand >>> where >>> some of the remaining programming difficulties remain. Based on this >>> attempt, I find several areas to strengthen, the most prominent of >>> which is how we use transactions. Another is to add the concept of a >>> catalog as a special kind of object store. >> >> Hi Nikunj, >> >> Thanks for replying! I'm very interested in getting this stuff sorted >> out pretty quickly as almost all other proposals in one way or another >> are affected by how this stuff develops. >> >>> Here are the main areas I propose to address in the editor's spec: >>> >>> 1. It is time to separate the dynamic and static scope transaction >>> creation so that they are asynchronous and synchronous respectively. >> >> I don't really understand what this means. What are dynamic and static >> scope transaction creation? Can you elaborate? > > This is the difference in the API in my email between openTransaction > and > transaction. Dynamic and static scope have been defined in the spec for > a > long time. >>> >>> In fact, dynamic transactions aren't explicitly specified anywhere. They are >>> just mentioned. You need some amount of guessing to find out what they are >>> or how to create one (i.e. pass an empty list of store names). >> >> Yes, that has been a big problem for us too. >> Ah, I think I'm following you now. I'm actually not sure that we should have dynamic scope at all in the spec, I know Jeremy has expressed similar concerns. However if we are going to have dynamic scope, I agree it is a good idea to have separate APIs for starting dynamic-scope transactions from static-scope transactions. >>> >>> I think it would simplify matters a lot if we were to drop dynamic >>> transactions altogether. And if we do that, then we can also safely move >>> the 'mode' to parameter to the Transaction interface, since all the object >>> stores in a static transaction can be only be open in the same mode. >> >> Agreed. >> >>> 2. Provide a catalog object that can be used to atomically add/remove >>> object stores and indexes as well as modify version. >> >> It seems to me that a catalog object doesn't really provide any >> functionality over the proposal in bug 10052? The advantage that I see >> with the syntax proposal in bug 10052 is that it is simpler. >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 >> >> Can you elaborate on what the advantages are of catalog objects? > > To begin with, 10052 shuts down the "users" of the database completely > when > only one is changing its structure, i.e., adding or removing an object > store. This is not the case. Check the steps defined for setVersion in [1]. At no point are databases shut down automatically. Only once all existing database connections are manually closed, either by calls to IDBDatabase.close() or by the user leaving the page, is the 'success' event from setVersion fired. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0 > How can we make it less draconian? The 'versionchange' event allows pages that are currently using the database to handle the change. The page can inspect the new version number supplied by the 'versionchange' event, and if it knows that it is compatible with a given upgrade, all it needs to do is to call db.close() and then immediately reopen the database using indexedDB.open(). The open call won't complete until the upgrade is finished. >>> >>> I had a question here: why does the page need to call 'close'? Any pending >>> transactions will run to completion and new ones should not be allowed to >>> start if a VERSION_CHANGE transaction is waiting to start. From the >>> description of what 'close' does in 10052, I am not entirely sure it is >>> needed. >> >> The p
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Fri, Jul 9, 2010 at 4:42 PM, Maciej Stachowiak wrote:
>
> On Jul 8, 2010, at 3:47 PM, Eric Uhrhane wrote:
>
>> On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking wrote:
>>> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
The biggest unknown in the current BlobWriter spec [1] is how you
obtain one in the first place.
There are two current proposals, which I've summarized below. I've
heard only a few voices on this topic, and would love to get more
opinions. New proposals would be welcome as well.
If you favor one of the below, and don't think I've done it justice,
please do weigh in with further details.
Proposal A: a new input control.
You'd add markup such as or .
It could be styled however you please; it would pop up a standard
File-SaveAs dialog, so there's no security problem there. You'd
handle the event when the user selects a save location in order to
grab the BlobWriter.
Pluses:
It parallels .
It's user-initiated, so the default flow doesn't ever surprise the
user with a popup.
Proposal B: a new method on Window.
window.saveAs(function(blobWriter) { /* grab the writer and use it
*/}, function(error) {...});
Pluses:
It's a simple async API like many others we provide.
App developers are free to provide any UI or control flow they like.
In either case, we could add a parameter for the Blob, so that the
system knows what it's saving, and/or a suggested mime-type and base
name. Adding the Blob itself would let us eliminate the
writeFile()/save() call mentioned in [2], so that you'd only grab the
returned BlobWriter if you wanted to handle the progress events.
>>>
>>> I'm not a fan of the solution. In part because no
>>> actual input is occurring. If we really want something like that then
>>> I think reviving the old element is the way to go.
>>
>> The user is inputting a location at which to save the file.
>>
>>> However what I really think we should do is to provide some API which
>>> given a blob and an optional filename, asynchronously returns an
>>> object at which progress events are fired and which has an abort()
>>> function. I don't care much if this function lives on a new object,
>>> a'la SimpleFileWriter, or if it's added to something like the
>>> Navigator object.
>>
>> OK, I'm not hearing any support whatsoever for option A, so let's go
>> with something like SimpleFileWriter/BlobSaver.
>>
>> How about this?
>>
>> var blobSaver = window.saveAs(blob);
>> blobSaver.onerror = onError;
>> blobSaver.onwriteend = onWriteEnd;
>
> It would be great if we could avoid adding methods to Window with simple and
> common names like saveAs(), since they pollute the global namespace. saveAs
> sounds like a name that may well conflict with existing code. FileSaver or
> BlobSaver would be less likely to conflict, so perhaps the entry point can be
> a constructor, rather than a function.
More like this?
var writer = new SimpleFileWriter(blob, optionalName);
writer.onerror = onError;
writer.onwriteend = onWriteEnd;
> Other thoughts:
> - I still think the names should be prefixed with File, not Blob.
That's fine for the writers; I like your logic that a FooWriter writes
to a Foo, not from it.
I think the converse is true for a reader, so BlobReader makes the most sense.
> - What would the behavior be? Would this pop up a dialog where the user picks
> a file? If so, should it be subject to a user gesture limitation?
Should we spec that, or leave it loose?
One option I was just discussing over here was that if it's in
response to a user gesture, it pops up a SaveAs dialog; if it's not,
it goes to an infobar. I don't want to spec this so closely that UAs
can't experiment a bit.
> - Part of the objection to is because there is no input
> occuring. But HTML5 also has an element. Perhaps
> is an option worth considering?
>
>
> Regards,
> Maciej
>
>
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Fri, 9 Jul 2010, Maciej Stachowiak wrote: > > - Part of the objection to is because there is no > input occuring. But HTML5 also has an element. Perhaps type=file> is an option worth considering? is more like than . We could reintroduce though if people want an in-page UA-feature UI. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: How to get a FileWriter/BlobWriter/BlobSaver
On Jul 8, 2010, at 3:47 PM, Eric Uhrhane wrote:
> On Fri, Jul 2, 2010 at 8:19 PM, Jonas Sicking wrote:
>> On Thu, Jul 1, 2010 at 3:31 PM, Eric Uhrhane wrote:
>>> The biggest unknown in the current BlobWriter spec [1] is how you
>>> obtain one in the first place.
>>> There are two current proposals, which I've summarized below. I've
>>> heard only a few voices on this topic, and would love to get more
>>> opinions. New proposals would be welcome as well.
>>>
>>> If you favor one of the below, and don't think I've done it justice,
>>> please do weigh in with further details.
>>>
>>>
>>> Proposal A: a new input control.
>>>
>>> You'd add markup such as or .
>>> It could be styled however you please; it would pop up a standard
>>> File-SaveAs dialog, so there's no security problem there. You'd
>>> handle the event when the user selects a save location in order to
>>> grab the BlobWriter.
>>>
>>> Pluses:
>>> It parallels .
>>> It's user-initiated, so the default flow doesn't ever surprise the
>>> user with a popup.
>>>
>>>
>>> Proposal B: a new method on Window.
>>>
>>> window.saveAs(function(blobWriter) { /* grab the writer and use it
>>> */}, function(error) {...});
>>>
>>> Pluses:
>>> It's a simple async API like many others we provide.
>>> App developers are free to provide any UI or control flow they like.
>>>
>>>
>>> In either case, we could add a parameter for the Blob, so that the
>>> system knows what it's saving, and/or a suggested mime-type and base
>>> name. Adding the Blob itself would let us eliminate the
>>> writeFile()/save() call mentioned in [2], so that you'd only grab the
>>> returned BlobWriter if you wanted to handle the progress events.
>>
>> I'm not a fan of the solution. In part because no
>> actual input is occurring. If we really want something like that then
>> I think reviving the old element is the way to go.
>
> The user is inputting a location at which to save the file.
>
>> However what I really think we should do is to provide some API which
>> given a blob and an optional filename, asynchronously returns an
>> object at which progress events are fired and which has an abort()
>> function. I don't care much if this function lives on a new object,
>> a'la SimpleFileWriter, or if it's added to something like the
>> Navigator object.
>
> OK, I'm not hearing any support whatsoever for option A, so let's go
> with something like SimpleFileWriter/BlobSaver.
>
> How about this?
>
>var blobSaver = window.saveAs(blob);
>blobSaver.onerror = onError;
>blobSaver.onwriteend = onWriteEnd;
It would be great if we could avoid adding methods to Window with simple and
common names like saveAs(), since they pollute the global namespace. saveAs
sounds like a name that may well conflict with existing code. FileSaver or
BlobSaver would be less likely to conflict, so perhaps the entry point can be a
constructor, rather than a function.
Other thoughts:
- I still think the names should be prefixed with File, not Blob.
- What would the behavior be? Would this pop up a dialog where the user picks a
file? If so, should it be subject to a user gesture limitation?
- Part of the objection to is because there is no input
occuring. But HTML5 also has an element. Perhaps
is an option worth considering?
Regards,
Maciej
Re: BlobWriter simplification/split
On Jul 8, 2010, at 5:03 PM, Jonas Sicking wrote: > On Thu, Jul 8, 2010 at 4:05 PM, Eric Uhrhane wrote: >> >> I don't see what's wrong with the name Blob; I like it just fine. And >> I think it's a bit odd to have a BlobReader but a FileWriter, but if >> that's what everybody's happy with, I'm OK with it. > > I could be convinced to rename BlobReader to FileReader ;-) Likewise. - Maciej
Re: [IndexedDB] Current editor's draft
On Fri, Jul 9, 2010 at 11:27 AM, Nikunj Mehta wrote:
>
> On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
>
> 2. Provide a catalog object that can be used to atomically add/remove
> object stores and indexes as well as modify version.
It seems to me that a catalog object doesn't really provide any
functionality over the proposal in bug 10052? The advantage that I see
with the syntax proposal in bug 10052 is that it is simpler.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
Can you elaborate on what the advantages are of catalog objects?
>>>
>>> To begin with, 10052 shuts down the "users" of the database completely when
>>> only one is changing its structure, i.e., adding or removing an object
>>> store.
>>
>> This is not the case. Check the steps defined for setVersion in [1].
>> At no point are databases shut down automatically. Only once all
>> existing database connections are manually closed, either by calls to
>> IDBDatabase.close() or by the user leaving the page, is the 'success'
>> event from setVersion fired.
>
> Can you justify why one should be forced to stop using the database when
> someone else is adding an object store or an index? This is what I meant by
> draconian.
In the thread "[IndexedDB] Atomic schema changes" the conclusion was
that while it's possible to create API that allows compatible schema
changes without calling setVersion, it wasn't worth the added API
complexity. It's something that can wait for v2. Are calls to add
indexes and objectStores without further incompatible changes common
enough that we need to optimize the case when users have multiple tabs
open? Remember that calling setVersion really is no overhead if only
one copy of the application is running.
>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0
>>
>>> How can we make it less draconian?
>>
>> The 'versionchange' event allows pages that are currently using the
>> database to handle the change. The page can inspect the new version
>> number supplied by the 'versionchange' event, and if it knows that it
>> is compatible with a given upgrade, all it needs to do is to call
>> db.close() and then immediately reopen the database using
>> indexedDB.open(). The open call won't complete until the upgrade is
>> finished.
>>
>>> Secondly, I don't see how that
>>> approach can produce atomic changes to the database.
>>
>> When the transaction created in step 4 of setVersion defined in [1] is
>> created, only one IDBDatabase object to the database is open. As long
>> as that transaction is running, no requests returned from
>> IDBFactory.open will receive a 'success' event. Only once the
>> transaction is committed, or aborted, will those requests succeed.
>> This guarantees that no other IDBDatabase object can see a partial
>> update.
>>
>> Further, only once the transaction created by setVersion is committed,
>> are the requested objectStores and indexes created/removed. This
>> guarantees that the database is never left with a partial update.
>>
>> That means that the changes are atomic, right?
>
> Atomic is not the same is isolated. Merely the fact that no other use of the
> database was being made when you are changing its structure doesn't mean that
> you will get all of the changes or none. What happens, for example, if the
> browser crashes in the middle of the versionRequest.onsuccess handler?
Yeah, I forgot one critical piece of information. Like with any other
transaction. If the transaction isn't successfully committed, it is
fully rolled back and no changes whatsoever are made to the database.
>>> Thirdly, we shouldn't
>>> need to change version in order to perform database changes.
>>
>> First off, note that if the upgrade is compatible, you can just pass
>> the existing database version to setVersion. So no version *change* is
>> actually needed.
>>
>> Second, I don't think there is much difference between
>>
>> var txn = db.transaction();
>> db.openCatalog(txn).onsuccess = ...
>>
>> vs
>>
>> db.setVersion("5").onsuccess = ...
>>
>> I don't see that telling people that they have to use the former is a big
>> win.
>>
>>
>> The problem that I see with the catalog proposal, if I understand it
>> correctly, is that it means that a page that has a IDBDatabase object
>> open has to always be prepared for calls to
>> openObjectStore/openTransaction failing. I.e. the page can't ever know
>> that another page was opened which at any point created a catalog and
>> removed an objectStore. This forces pages to at every single call
>> either check that the version is still the same, or that each and
>> every call to openObjectStore/openTransaction succeeds. This seems
>> very error prone to me.
>
> We could easily add a condition check to removing an object store so that
> there are no open transactions holding a lock on that object store. This
> would prevent any errors of the kind you describe.
I don't see that that would help. You're still i
Re: [IndexedDB] Current editor's draft
On 7/9/2010 12:50 PM, Nikunj Mehta wrote: The point is that we are talking of leaving out dynamic scope in v1, while, in the same vein, talking of making READ_ONLY the default _because_ it produces "good" performance. That is, IMHO, contradictory. Dynamic scope == dynamic transactions, correct? Can you please elaborate on how dynamic transactions improve performance? This seems to be conveniently justified. A strict interpretation of the objective would not require the programmer to specify READ_WRITE even though that involves less mental (cognitive) and physical (typing) effort. FWIW, this isn't constructive. Your argument also seems to assume that writes are more common than reads, which hasn't been my experience with this API. It should have worked right the first time. Why wait for a programmer to find out why their code didn't work? Why make writing code with good performance characteristics the uncommon case? We clearly have two different schools of thoughts here, and I'm not sure we are going to find a consensus... There are many ways to get performance improvement, including dynamic transactions, which you seem not to be favorable towards. I don't see why READ_ONLY should be given special treatment. It's unclear to me why you think READ_ONLY is getting special treatment (or what that even means in this context). Various hints are used in SQL syntax, e.g., [1], to manage locks, a certain kind of B-tree behavior, or a level of isolation. These are all aimed at improving performance, but they are set as default behavior. My point is that expecting good performance from a single variable in database systems out of possibly hundreds is not all that helpful. It is also a slippery slope because it confuses performance with options. The database's job is to be fast at what it does, not play performance tricks using default values. While I think this argument makes sense in some cases, I really don't feel like it applies at all in this situation. Even the page you linked to says "Because the SQL Server query optimizer typically selects the best execution plan for a query..." which in most cases would be READ_ONLY (based on evidence the Mozilla team has from demos written). The default should represent the commonly used case. I don't know that we can make the right performance decisions for people. What we can do is make things perform well and provide tools to improve performance. We aren't making performance decisions though; we are just picking the default to be the most commonly used option. It just happens to be the one to allow more concurrency. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Current editor's draft
On 7/9/2010 11:05 AM, Nikunj Mehta wrote: We would not make dynamic transactions be the default since they would produce more concurrency than static scoped transactions, correct? I'm still of the opinion that dynamic transactions are a bad idea because it's too easy to hold a transaction open for a long period of time, making it easy for programmers to write incorrect/buggy code. All along our primary objective with IndexedDB is to assist programmers who are not well versed with database programming to be able to write simple programs without errors. By that token, reducing the effort required for their use of IndexedDB seems to be the primary criteria and not great concurrency. Er, I thought we were targeting libraries but still wanted this to be simple to use. Regardless, allowing for more concurrency doesn't hurt ease of use in any of what we've discussed so far (as far as I can tell). Another downside is that authors should specify lock-type more often, for optimal performance, if we think that READ_ONLY is more common. You haven't provided any evidence about this yet. I can assert that all the demos I've written (admittedly not many), simply reading from the database has been far more common than writing to it. It's pretty much "write data in" but then do all operations on the local database. It is quite common in various languages to specify as a performance or safety hint when someone desires a shared lock and use a read-write version by default. You seem to have contradictory statements here. Earlier you argued that "reducing the effort required for their [programmers] use of IndexedDB seems to be the primary criteria", but having them to read and know performance or safety hints seems to me like we are making the API more complicated. Having simple clear API calls with sensible error messages on misuse is far better than having an API that you can use one way (the most common way) but would be more efficient if you use it another way. For all we know, programmers would lock the entire database when they create a transaction. If dynamic transactions appear to be a non-v1 feature, then READ_ONLY being default appears out of place. You asked Jonas for data backing up his claims, and now I'm going to ask the same of you. It's been my experience and Ben Turner's experience that defaulting to READ_ONLY results in less code being written using this API. Reads are far more common than writes (in databases in general, I think although edge cases certainly exist), so it makes sense to make that the default. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Current editor's draft
Hi Nikunj, On Fri, Jul 9, 2010 at 7:31 PM, Nikunj Mehta wrote: > Andrei, > > Pejorative remarks about normative text don't help anyone. If you think that > the spec text is not clear or that you are unable to interpret it, please say > so. The text about dynamic scope has been around for long enough and no one > so far mentioned a problem with them. > I didn't mean anything disrespectful, I'm sorry if it sounded that way. I was just stating that, as far as I can tell, the spec is not clear about dynamic transactions. Thanks, Andrei
Re: [IndexedDB] Current editor's draft
On Jul 10, 2010, at 12:29 AM, Jonas Sicking wrote: > On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta wrote: >> We would not make dynamic transactions be the default since they would >> produce more concurrency than static scoped transactions, correct? >> On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote: > > I'm not sure I understand the question. We would use separate > functions for creating dynamic and static transactions so there is no > such thing as "default". The point is that we are talking of leaving out dynamic scope in v1, while, in the same vein, talking of making READ_ONLY the default _because_ it produces "good" performance. That is, IMHO, contradictory. > >> Unless we're planning on making all >> transactions dynamic (I hope not), locks have to be grabbed when the >> transaction is created, right? If a transaction is holding a READ_ONLY >> >> lock for a given objectStore, then attempting to open that objectStore >> >> as READ_WRITE should obviously fail. Consecutively, if a transaction >> >> is holding a READ_WRITE lock for a given objectStore, then opening >> >> that objectStore as READ_ONLY doesn't seem to have any benefit over >> >> opening it as READ_WRITE. In short, I can't see any situation when >> >> you'd want to open an objectStore in a different mode than what was >> >> used when the transaction was created. >> >> Finally, I would stronly prefer to have READ_ONLY be the default >> >> transaction type if none is specified by the author. It is better to >> >> default to what results in higher performance, and have people notice >> >> when they need to switch to the slower mode. This is because people >> >> will very quickly notice if they use READ_ONLY when they need to use >> >> READ_WRITE, since the code will never work. However if people use >> >> READ_WRITE when all they need is READ_ONLY, then the only effect is >> >> likely to be an application that runs somewhat slower, when they will >> >> unlikely detect. >> >> This approach is also likely to cause exceptions upon put, remove, and add. >> >> I would prefer to not cause exceptions as the default behavior. >> >> If we use READ_WRITE as default behavior then it's extremely likely >> that people will use the wrong lock type and not realize. The downside >> will be that sites will run less concurrently, and thus slower, than >> they could. >> >> All along our primary objective with IndexedDB is to assist programmers who >> are not well versed with database programming to be able to write simple >> programs without errors. By that token, reducing the effort required for >> their use of IndexedDB seems to be the primary criteria and not great >> concurrency. > > As far as I can see this does not significantly complicate > development. This seems to be conveniently justified. A strict interpretation of the objective would not require the programmer to specify READ_WRITE even though that involves less mental (cognitive) and physical (typing) effort. > In fact, in the process of writing test cases I have > several times forgotten to specify lock type. For the cases when I > needed a READ_WRITE lock, the code didn't work. It should have worked right the first time. Why wait for a programmer to find out why their code didn't work? > As always when things > don't work my first reaction was to go look at the error console which > showed a uncaught exception which immediately showed what the problem > was. > > So I argue that this does not meaningfully increase the effort > required to use IndexedDB. > > Using the other lock type as default does however meaningfully > increase the effort required to get optimal performance, which I think > we should take into account. There are many ways to get performance improvement, including dynamic transactions, which you seem not to be favorable towards. I don't see why READ_ONLY should be given special treatment. > >> Another downside is that authors should specify lock-type >> more often, for optimal performance, if we think that READ_ONLY is >> more common. >> >> You haven't provided any evidence about this yet. > > Certainly. I was just enumerating all the reasons I could think of why > either default would be preferable. I similarly haven't seen any > evidence why write transactions are more common. > > Though I will note that both the example programs that you have > written, as well as ones we have written for a few demos, use more > read transactions than write transactions. (I can attach those if > anyone is interested, though note that they are very specific to the > API we currently have implemented). > >> If we are using READ_ONLY as default behavior, then it's extremely >> likely that people will use the wrong lock type, notice that their >> code isn't working, and fix it. The downside is that people will have >> to fix their bugs. Another downside is that authors will have to >> specify lock-type more often if we think that READ_WRITE is m
Re: [IndexedDB] Current editor's draft
On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote:
>
> One of our main points was to make getting objectStore
> objects a synchronous operation as to avoid having to nest multiple
> levels of asynchronous calls. Compare
>
> var req = db.openObjectStore("foo", trans);
> req.onerror = errorHandler;
> req.onsuccess = function(e) {
> var fooStore = e.result;
> var req = fooStore.get(12);
> req.onerror = errorHandler;
> req.onsuccess = resultHandler;
> }
>
> to
>
> var fooStore = db.openObjectStore("foo", trans);
> var req = fooStore.get(12);
> req.onerror = errorHandler;
> req.onsuccess = resultHandler;
>
>
> I also don't understand the advantage of having the transaction as an
> argument to openObjectStore rather than having openObjectStore live on
> transaction. Compare
>
> db.openObjectStore("foo", trans);
>
> to
>
> trans.openObjectStore("foo");
>
> I also don't understand the meaning of specifying a mode when a
> objectStore is opened, rather than specifying the mode when the
> transaction is created.
Have you reviewed the examples? Different object stores in a transaction
are
used in different modes, and that requires us to identify the mode when
opening the object store. This also increases concurrency. This is
particularly useful for dynamic transactions.
>>>
>>> I'm following you better now. I do see how this can work for dynamic
>>> transactions where locks are not acquired upon creation of the
>>> transaction. But I don't see how this makes sense for static
>>> transactions. And it indeed seems like you are not using this feature
>>> for static transactions.
The feature is targeted for use in dynamic scope.
>>>
>>
>> I don't think it's even possible with the current API since
>> openTransaction() takes a list of objectStore names but a single mode.
>
> Indeed. We could allow static transactions to use different lock
> levels for different objectStores, all specified when the
> IDBTransaction is initially created. It's just a matter of syntax to
> the IDBDatabase.transaction() function. However so far I've thought
> that we should leave this for v2. But if people would feel more easy
> about dropping dynamic transactions if we add this ability, then I
> would be ok with it.
From my examples, it was clear that we need different object stores to be
opened in different modes. Currently dynamic scope supports this use case,
i.e., allow mode specification on a per object-store basis. Therefore, unless
we decide to de-support this use case, we would need to add this ability to
static scope transactions if dynamic scope transactions go out of v1.
>
>>> If it is the case that specifying a mode when opening an objectStore
>>> only makes sense on dynamic transactions, then I think we should only
>>> expose that argument on dynamic transactions.
>>>
>>> Now that I understand your proposal better, I don't understand how
>>> IDBTransaction.objectStore works for dynamically scoped transactions
>>> in your proposal. It seems to require synchronously grabbing a lock
>>> which I thought we wanted to avoid at all cost.
See below.
>>>
>>
>> This is rather confusing: is IDBTransaction::objectStore() creating an
>> object store, now? If yes, then it must lock it synchronously. If it just
>> returns an object store that was previously added to the transaction, what
>> is the 'mode' parameter for?
>
> Looking at Nikunj's example code, it seems like you can request a new
> objectStore to be locked using IDBTransaction.objectStore(). Not sure
> if that is a bug or not though?
That was a bug. For dynamic transactions, obtaining an object store would have
to be asynchronous as it involves obtaining a lock.
I also did not hear from you about explicit commits. Did that mean that you
agree with that part of my proposal? There are several examples where it makes
sense to explicitly commit, although it is automatic in some cases.
Re: [IndexedDB] Current editor's draft
On Jul 8, 2010, at 4:17 AM, Shawn Wilsher wrote: > On 7/6/2010 6:31 PM, Nikunj Mehta wrote: >> To begin with, 10052 shuts down the "users" of the database completely when >> only one is changing its structure, i.e., adding or removing an object >> store. How can we make it less draconian? Secondly, I don't see how that >> approach can produce atomic changes to the database. Thirdly, we shouldn't >> need to change version in order to perform database changes. Finally, I am >> not sure why you consider the syntax proposal simpler. Note that I am not >> averse to the version change event notification. > In what use case would you want to change the database structure without > modifying the version? That almost seems like a footgun for consumers. > Can you justify your conclusion?
Re: [IndexedDB] Current editor's draft
On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote: > On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote: >> >> >> On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote: >>> >>> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote: On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote: > > On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta > wrote: >> Hi folks, >> >> There are several unimplemented proposals on strengthening and >> expanding IndexedDB. The reason I have not implemented them yet is >> because I am not convinced they are necessary in toto. Here's my >> attempt at explaining why. I apologize in advance for not responding >> to individual proposals due to personal time constraints. I will >> however respond in detail on individual bug reports, e.g., as I did >> with 9975. >> >> I used the current editor's draft asynchronous API to understand >> where >> some of the remaining programming difficulties remain. Based on this >> attempt, I find several areas to strengthen, the most prominent of >> which is how we use transactions. Another is to add the concept of a >> catalog as a special kind of object store. > > Hi Nikunj, > > Thanks for replying! I'm very interested in getting this stuff sorted > out pretty quickly as almost all other proposals in one way or another > are affected by how this stuff develops. > >> Here are the main areas I propose to address in the editor's spec: >> >> 1. It is time to separate the dynamic and static scope transaction >> creation so that they are asynchronous and synchronous respectively. > > I don't really understand what this means. What are dynamic and static > scope transaction creation? Can you elaborate? This is the difference in the API in my email between openTransaction and transaction. Dynamic and static scope have been defined in the spec for a long time. >>> >> >> In fact, dynamic transactions aren't explicitly specified anywhere. They are >> just mentioned. You need some amount of guessing to find out what they are >> or how to create one (i.e. pass an empty list of store names). > > Yes, that has been a big problem for us too. > >>> Ah, I think I'm following you now. I'm actually not sure that we >>> should have dynamic scope at all in the spec, I know Jeremy has >>> expressed similar concerns. However if we are going to have dynamic >>> scope, I agree it is a good idea to have separate APIs for starting >>> dynamic-scope transactions from static-scope transactions. >>> >> >> I think it would simplify matters a lot if we were to drop dynamic >> transactions altogether. And if we do that, then we can also safely move >> the 'mode' to parameter to the Transaction interface, since all the object >> stores in a static transaction can be only be open in the same mode. > > Agreed. > >> 2. Provide a catalog object that can be used to atomically add/remove >> object stores and indexes as well as modify version. > > It seems to me that a catalog object doesn't really provide any > functionality over the proposal in bug 10052? The advantage that I see > with the syntax proposal in bug 10052 is that it is simpler. > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 > > Can you elaborate on what the advantages are of catalog objects? To begin with, 10052 shuts down the "users" of the database completely when only one is changing its structure, i.e., adding or removing an object store. >>> >>> This is not the case. Check the steps defined for setVersion in [1]. >>> At no point are databases shut down automatically. Only once all >>> existing database connections are manually closed, either by calls to >>> IDBDatabase.close() or by the user leaving the page, is the 'success' >>> event from setVersion fired. >>> >>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0 >>> How can we make it less draconian? >>> >>> The 'versionchange' event allows pages that are currently using the >>> database to handle the change. The page can inspect the new version >>> number supplied by the 'versionchange' event, and if it knows that it >>> is compatible with a given upgrade, all it needs to do is to call >>> db.close() and then immediately reopen the database using >>> indexedDB.open(). The open call won't complete until the upgrade is >>> finished. >>> >> >> I had a question here: why does the page need to call 'close'? Any pending >> transactions will run to completion and new ones should not be allowed to >> start if a VERSION_CHANGE transaction is waiting to start. From the >> description of what 'close' does in 10052, I am not entirely sure it is >> needed. > > The problem we're trying to solve is this: > > Imagine an editor which stores documents in indexedDB. However in > order to not overwrite the
Re: [IndexedDB] Current editor's draft
On Fri, Jul 9, 2010 at 11:05 AM, Nikunj Mehta wrote: > We would not make dynamic transactions be the default since they would > produce more concurrency than static scoped transactions, correct? > On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote: I'm not sure I understand the question. We would use separate functions for creating dynamic and static transactions so there is no such thing as "default". > Unless we're planning on making all > transactions dynamic (I hope not), locks have to be grabbed when the > transaction is created, right? If a transaction is holding a READ_ONLY > > lock for a given objectStore, then attempting to open that objectStore > > as READ_WRITE should obviously fail. Consecutively, if a transaction > > is holding a READ_WRITE lock for a given objectStore, then opening > > that objectStore as READ_ONLY doesn't seem to have any benefit over > > opening it as READ_WRITE. In short, I can't see any situation when > > you'd want to open an objectStore in a different mode than what was > > used when the transaction was created. > > Finally, I would stronly prefer to have READ_ONLY be the default > > transaction type if none is specified by the author. It is better to > > default to what results in higher performance, and have people notice > > when they need to switch to the slower mode. This is because people > > will very quickly notice if they use READ_ONLY when they need to use > > READ_WRITE, since the code will never work. However if people use > > READ_WRITE when all they need is READ_ONLY, then the only effect is > > likely to be an application that runs somewhat slower, when they will > > unlikely detect. > > This approach is also likely to cause exceptions upon put, remove, and add. > > I would prefer to not cause exceptions as the default behavior. > > If we use READ_WRITE as default behavior then it's extremely likely > that people will use the wrong lock type and not realize. The downside > will be that sites will run less concurrently, and thus slower, than > they could. > > All along our primary objective with IndexedDB is to assist programmers who > are not well versed with database programming to be able to write simple > programs without errors. By that token, reducing the effort required for > their use of IndexedDB seems to be the primary criteria and not great > concurrency. As far as I can see this does not significantly complicate development. In fact, in the process of writing test cases I have several times forgotten to specify lock type. For the cases when I needed a READ_WRITE lock, the code didn't work. As always when things don't work my first reaction was to go look at the error console which showed a uncaught exception which immediately showed what the problem was. So I argue that this does not meaningfully increase the effort required to use IndexedDB. Using the other lock type as default does however meaningfully increase the effort required to get optimal performance, which I think we should take into account. > Another downside is that authors should specify lock-type > more often, for optimal performance, if we think that READ_ONLY is > more common. > > You haven't provided any evidence about this yet. Certainly. I was just enumerating all the reasons I could think of why either default would be preferable. I similarly haven't seen any evidence why write transactions are more common. Though I will note that both the example programs that you have written, as well as ones we have written for a few demos, use more read transactions than write transactions. (I can attach those if anyone is interested, though note that they are very specific to the API we currently have implemented). > If we are using READ_ONLY as default behavior, then it's extremely > likely that people will use the wrong lock type, notice that their > code isn't working, and fix it. The downside is that people will have > to fix their bugs. Another downside is that authors will have to > specify lock-type more often if we think that READ_WRITE is more > common. > > It is quite common in various languages to specify as a performance or > safety hint when someone desires a shared lock and use a read-write version > by default. I don't understand what you mean here. Could you elaborate? > To me the downsides of using READ_WRITE as a default are much worse > than the downsides of using READ_ONLY. > > For all we know, programmers would lock the entire database when they create > a transaction. If dynamic transactions appear to be a non-v1 feature, then > READ_ONLY being default appears out of place. I don't understand why the lack of dynamic transactions would affect what default lock type we should use for static transactions. In fact, if you are concerned that lack of dynamic transactions will cause people to lock the entire database and thus reduce concurrency (is that your concern?), then it seems like using READ_ONLY as default addresses that concern better than using READ
Re: [IndexedDB] Current editor's draft
Andrei, Pejorative remarks about normative text don't help anyone. If you think that the spec text is not clear or that you are unable to interpret it, please say so. The text about dynamic scope has been around for long enough and no one so far mentioned a problem with them. Nikunj On Jul 7, 2010, at 11:11 PM, Andrei Popescu wrote: > In fact, dynamic transactions aren't explicitly specified anywhere. They are > just mentioned. You need some amount of guessing to find out what they are or > how to create one (i.e. pass an empty list of store names). >
Re: [IndexedDB] Current editor's draft
On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote:
2. Provide a catalog object that can be used to atomically add/remove
object stores and indexes as well as modify version.
>>>
>>> It seems to me that a catalog object doesn't really provide any
>>> functionality over the proposal in bug 10052? The advantage that I see
>>> with the syntax proposal in bug 10052 is that it is simpler.
>>>
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
>>>
>>> Can you elaborate on what the advantages are of catalog objects?
>>
>> To begin with, 10052 shuts down the "users" of the database completely when
>> only one is changing its structure, i.e., adding or removing an object
>> store.
>
> This is not the case. Check the steps defined for setVersion in [1].
> At no point are databases shut down automatically. Only once all
> existing database connections are manually closed, either by calls to
> IDBDatabase.close() or by the user leaving the page, is the 'success'
> event from setVersion fired.
Can you justify why one should be forced to stop using the database when
someone else is adding an object store or an index? This is what I meant by
draconian.
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0
>
>> How can we make it less draconian?
>
> The 'versionchange' event allows pages that are currently using the
> database to handle the change. The page can inspect the new version
> number supplied by the 'versionchange' event, and if it knows that it
> is compatible with a given upgrade, all it needs to do is to call
> db.close() and then immediately reopen the database using
> indexedDB.open(). The open call won't complete until the upgrade is
> finished.
>
>> Secondly, I don't see how that
>> approach can produce atomic changes to the database.
>
> When the transaction created in step 4 of setVersion defined in [1] is
> created, only one IDBDatabase object to the database is open. As long
> as that transaction is running, no requests returned from
> IDBFactory.open will receive a 'success' event. Only once the
> transaction is committed, or aborted, will those requests succeed.
> This guarantees that no other IDBDatabase object can see a partial
> update.
>
> Further, only once the transaction created by setVersion is committed,
> are the requested objectStores and indexes created/removed. This
> guarantees that the database is never left with a partial update.
>
> That means that the changes are atomic, right?
Atomic is not the same is isolated. Merely the fact that no other use of the
database was being made when you are changing its structure doesn't mean that
you will get all of the changes or none. What happens, for example, if the
browser crashes in the middle of the versionRequest.onsuccess handler?
>> Thirdly, we shouldn't
>> need to change version in order to perform database changes.
>
> First off, note that if the upgrade is compatible, you can just pass
> the existing database version to setVersion. So no version *change* is
> actually needed.
>
> Second, I don't think there is much difference between
>
> var txn = db.transaction();
> db.openCatalog(txn).onsuccess = ...
>
> vs
>
> db.setVersion("5").onsuccess = ...
>
> I don't see that telling people that they have to use the former is a big win.
>
>
> The problem that I see with the catalog proposal, if I understand it
> correctly, is that it means that a page that has a IDBDatabase object
> open has to always be prepared for calls to
> openObjectStore/openTransaction failing. I.e. the page can't ever know
> that another page was opened which at any point created a catalog and
> removed an objectStore. This forces pages to at every single call
> either check that the version is still the same, or that each and
> every call to openObjectStore/openTransaction succeeds. This seems
> very error prone to me.
We could easily add a condition check to removing an object store so that there
are no open transactions holding a lock on that object store. This would
prevent any errors of the kind you describe.
>
> Looking at your example, it also seems like it contains a race
> condition. There is a risk that when someone opens a database, the
> first transaction, which uses a catalog to create the necessary
> objectStores and indexes, is committed, but the second transaction,
> which populates the objectStores with data, has not yet started.
I purposely wrote my example to allow database to be populated separately from
the creation of the database. There is no reason why the two couldn't be done
in the same transaction, though.
>
>> Finally, I am
>> not sure why you consider the syntax proposal simpler. Note that I am not
>> averse to the version change event notification.
>
> Compare to how your code would look like with the proposals in bugs
> 9975 and 10052:
>
> var db;
> var dbRequest = indexedDB.open("parts", 'Part database');
> dbRequest.onsuccess = function(event) {
> db = event.result;
> if
Re: [IndexedDB] Current editor's draft
We would not make dynamic transactions be the default since they would produce more concurrency than static scoped transactions, correct? On Jul 7, 2010, at 12:57 PM, Jonas Sicking wrote: >>> Unless we're planning on making all >>> transactions dynamic (I hope not), locks have to be grabbed when the >>> transaction is created, right? If a transaction is holding a READ_ONLY >>> lock for a given objectStore, then attempting to open that objectStore >>> as READ_WRITE should obviously fail. Consecutively, if a transaction >>> is holding a READ_WRITE lock for a given objectStore, then opening >>> that objectStore as READ_ONLY doesn't seem to have any benefit over >>> opening it as READ_WRITE. In short, I can't see any situation when >>> you'd want to open an objectStore in a different mode than what was >>> used when the transaction was created. >>> >>> Finally, I would stronly prefer to have READ_ONLY be the default >>> transaction type if none is specified by the author. It is better to >>> default to what results in higher performance, and have people notice >>> when they need to switch to the slower mode. This is because people >>> will very quickly notice if they use READ_ONLY when they need to use >>> READ_WRITE, since the code will never work. However if people use >>> READ_WRITE when all they need is READ_ONLY, then the only effect is >>> likely to be an application that runs somewhat slower, when they will >>> unlikely detect. >> >> This approach is also likely to cause exceptions upon put, remove, and add. >> I would prefer to not cause exceptions as the default behavior. > > If we use READ_WRITE as default behavior then it's extremely likely > that people will use the wrong lock type and not realize. The downside > will be that sites will run less concurrently, and thus slower, than > they could. All along our primary objective with IndexedDB is to assist programmers who are not well versed with database programming to be able to write simple programs without errors. By that token, reducing the effort required for their use of IndexedDB seems to be the primary criteria and not great concurrency. > Another downside is that authors should specify lock-type > more often, for optimal performance, if we think that READ_ONLY is > more common. You haven't provided any evidence about this yet. > > If we are using READ_ONLY as default behavior, then it's extremely > likely that people will use the wrong lock type, notice that their > code isn't working, and fix it. The downside is that people will have > to fix their bugs. Another downside is that authors will have to > specify lock-type more often if we think that READ_WRITE is more > common. It is quite common in various languages to specify as a performance or safety hint when someone desires a shared lock and use a read-write version by default. > > To me the downsides of using READ_WRITE as a default are much worse > than the downsides of using READ_ONLY. For all we know, programmers would lock the entire database when they create a transaction. If dynamic transactions appear to be a non-v1 feature, then READ_ONLY being default appears out of place.
Re: [IndexedDB] Current editor's draft
On Fri, Jul 9, 2010 at 3:21 AM, Andrei Popescu wrote: > On Thu, Jul 8, 2010 at 8:27 PM, Jonas Sicking wrote: >> On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote: >>> Hi Jonas, >>> >>> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote: On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote: > > > On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote: >> >> On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote: >> > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote: >> >> >> >> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta >> >> wrote: >> >> > Hi folks, >> >> > >> >> > There are several unimplemented proposals on strengthening and >> >> > expanding IndexedDB. The reason I have not implemented them yet is >> >> > because I am not convinced they are necessary in toto. Here's my >> >> > attempt at explaining why. I apologize in advance for not responding >> >> > to individual proposals due to personal time constraints. I will >> >> > however respond in detail on individual bug reports, e.g., as I did >> >> > with 9975. >> >> > >> >> > I used the current editor's draft asynchronous API to understand >> >> > where >> >> > some of the remaining programming difficulties remain. Based on this >> >> > attempt, I find several areas to strengthen, the most prominent of >> >> > which is how we use transactions. Another is to add the concept of a >> >> > catalog as a special kind of object store. >> >> >> >> Hi Nikunj, >> >> >> >> Thanks for replying! I'm very interested in getting this stuff sorted >> >> out pretty quickly as almost all other proposals in one way or another >> >> are affected by how this stuff develops. >> >> >> >> > Here are the main areas I propose to address in the editor's spec: >> >> > >> >> > 1. It is time to separate the dynamic and static scope transaction >> >> > creation so that they are asynchronous and synchronous respectively. >> >> >> >> I don't really understand what this means. What are dynamic and static >> >> scope transaction creation? Can you elaborate? >> > >> > This is the difference in the API in my email between openTransaction >> > and >> > transaction. Dynamic and static scope have been defined in the spec for >> > a >> > long time. >> > > In fact, dynamic transactions aren't explicitly specified anywhere. They > are > just mentioned. You need some amount of guessing to find out what they are > or how to create one (i.e. pass an empty list of store names). Yes, that has been a big problem for us too. >> Ah, I think I'm following you now. I'm actually not sure that we >> should have dynamic scope at all in the spec, I know Jeremy has >> expressed similar concerns. However if we are going to have dynamic >> scope, I agree it is a good idea to have separate APIs for starting >> dynamic-scope transactions from static-scope transactions. >> > > I think it would simplify matters a lot if we were to drop dynamic > transactions altogether. And if we do that, then we can also safely move > the 'mode' to parameter to the Transaction interface, since all the object > stores in a static transaction can be only be open in the same mode. Agreed. >> >> > 2. Provide a catalog object that can be used to atomically >> >> > add/remove >> >> > object stores and indexes as well as modify version. >> >> >> >> It seems to me that a catalog object doesn't really provide any >> >> functionality over the proposal in bug 10052? The advantage that I see >> >> with the syntax proposal in bug 10052 is that it is simpler. >> >> >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 >> >> >> >> Can you elaborate on what the advantages are of catalog objects? >> > >> > To begin with, 10052 shuts down the "users" of the database completely >> > when >> > only one is changing its structure, i.e., adding or removing an object >> > store. >> >> This is not the case. Check the steps defined for setVersion in [1]. >> At no point are databases shut down automatically. Only once all >> existing database connections are manually closed, either by calls to >> IDBDatabase.close() or by the user leaving the page, is the 'success' >> event from setVersion fired. >> >> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0 >> >> > How can we make it less draconian? >> >> The 'versionchange' event allows pages that are currently using the >> database to handle the change. The page can inspect the new version >> number supplied by the 'versionchange' event, and if it knows that it >> is compatible with a given upgrade, all it needs to do is to call >> db.close() and then immediately reopen the database
[Web Storage] A couple questions about the storage spec
Hello all,
I have a couple questions about the storage spec (I'm reading the June 15th
version at (http://dev.w3.org/html5/webstorage/).
(1) The spec says:
"The object's indices of the supported indexed properties are the numbers in
the range zero to one less than the number of key/value pairs currently present
in the list associated with the object. If the list is empty, then there are no
supported indexed properties."
As far as I can tell, this seems to say I should be able to say something like:
window.localStorage[3]
and get something back (not clear if the key or the value). Am I right in my
interpretation of that paragraph?
I saw some discussion earlier about whether something like localStorage[3] was
meaningful, but I didn't find the resolution. It does seem
undesirable/confusing to me. And none of the browsers I've tried this with do
this. So, I'm just confused, and probably misunderstanding "indices of the
supported indexed properties". Thanks for any clarification.
(2) The spec also says:
"The names of the supported named properties on a Storage object are the keys
of each key/value pair currently present in the list associated with the
object."
I read that (possibly/probably wrongly) as saying I should be able to say
window.localStorage.setItem("foo", "bar");
myVariable = window.localStorage["foo"];
and now myVariable will have "bar".
If my reading is right (and it is the behavior I see in a couple browsers) this
makes me very nervous, because I can do something like:
window.localStorage.setItem("length", "a value we computer");
window.localStorage.setItem("clear", "something that is transparent");
which of course allows:
window.localStorage["length"];
window.localStorage["clear"];
but in the browsers I've looked at, this (of course) also kinda messes up
things like:
for (index = 0; index < window.localStorage.length; index++) {
// whatever
}
window.localStorage.clear();
since length is now not a number, and clear isn't a function.
Why is this a desirable feature?
(3) Real nitpicking here:
The IDL for the Storage interface says
setter creator void setItem(in DOMString key, in any data);
but the text says
The setItem(key, value) method
Note the name of the second parameter is different between these.
Thank you. Despite my nitpicking above, I really appreciate the presence of
this spec! :-)
david
p.s. I'm still coming up to speed on these specs, so if I'm just
misunderstanding something basic, direct me to TFM that I should R.
[widgets] i18n tests
Hi i18n Core WG and WebApps WG, Opera today contributed to the W3C around 160 tests for testing dir and span in a widget's configuration document (links below). If you have time, please take a look at some of them. They were computationally generated, so if there is a general problem with the strings we are using, they can be easily fixed: http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/ http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-ltr/ http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rlo/ http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-rtl/ We have not yet generated the pass conditions in a human readable form, which we will do that in the coming weeks (to be included in [1]). [1] http://dev.w3.org/2006/waf/widgets/test-suite/ -- Marcos Caceres Opera Software ASA, http://www.opera.com/ http://datadriven.com.au
Re: [IndexedDB] Current editor's draft
On Thu, Jul 8, 2010 at 8:27 PM, Jonas Sicking wrote: > On Thu, Jul 8, 2010 at 8:22 AM, Andrei Popescu wrote: >> Hi Jonas, >> >> On Wed, Jul 7, 2010 at 8:08 PM, Jonas Sicking wrote: >>> On Wed, Jul 7, 2010 at 10:41 AM, Andrei Popescu wrote: On Wed, Jul 7, 2010 at 8:27 AM, Jonas Sicking wrote: > > On Tue, Jul 6, 2010 at 6:31 PM, Nikunj Mehta wrote: > > On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking wrote: > >> > >> On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta > >> wrote: > >> > Hi folks, > >> > > >> > There are several unimplemented proposals on strengthening and > >> > expanding IndexedDB. The reason I have not implemented them yet is > >> > because I am not convinced they are necessary in toto. Here's my > >> > attempt at explaining why. I apologize in advance for not responding > >> > to individual proposals due to personal time constraints. I will > >> > however respond in detail on individual bug reports, e.g., as I did > >> > with 9975. > >> > > >> > I used the current editor's draft asynchronous API to understand > >> > where > >> > some of the remaining programming difficulties remain. Based on this > >> > attempt, I find several areas to strengthen, the most prominent of > >> > which is how we use transactions. Another is to add the concept of a > >> > catalog as a special kind of object store. > >> > >> Hi Nikunj, > >> > >> Thanks for replying! I'm very interested in getting this stuff sorted > >> out pretty quickly as almost all other proposals in one way or another > >> are affected by how this stuff develops. > >> > >> > Here are the main areas I propose to address in the editor's spec: > >> > > >> > 1. It is time to separate the dynamic and static scope transaction > >> > creation so that they are asynchronous and synchronous respectively. > >> > >> I don't really understand what this means. What are dynamic and static > >> scope transaction creation? Can you elaborate? > > > > This is the difference in the API in my email between openTransaction > > and > > transaction. Dynamic and static scope have been defined in the spec for > > a > > long time. > In fact, dynamic transactions aren't explicitly specified anywhere. They are just mentioned. You need some amount of guessing to find out what they are or how to create one (i.e. pass an empty list of store names). >>> >>> Yes, that has been a big problem for us too. >>> > Ah, I think I'm following you now. I'm actually not sure that we > should have dynamic scope at all in the spec, I know Jeremy has > expressed similar concerns. However if we are going to have dynamic > scope, I agree it is a good idea to have separate APIs for starting > dynamic-scope transactions from static-scope transactions. > I think it would simplify matters a lot if we were to drop dynamic transactions altogether. And if we do that, then we can also safely move the 'mode' to parameter to the Transaction interface, since all the object stores in a static transaction can be only be open in the same mode. >>> >>> Agreed. >>> > >> > 2. Provide a catalog object that can be used to atomically add/remove > >> > object stores and indexes as well as modify version. > >> > >> It seems to me that a catalog object doesn't really provide any > >> functionality over the proposal in bug 10052? The advantage that I see > >> with the syntax proposal in bug 10052 is that it is simpler. > >> > >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052 > >> > >> Can you elaborate on what the advantages are of catalog objects? > > > > To begin with, 10052 shuts down the "users" of the database completely > > when > > only one is changing its structure, i.e., adding or removing an object > > store. > > This is not the case. Check the steps defined for setVersion in [1]. > At no point are databases shut down automatically. Only once all > existing database connections are manually closed, either by calls to > IDBDatabase.close() or by the user leaving the page, is the 'success' > event from setVersion fired. > > [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052#c0 > > > How can we make it less draconian? > > The 'versionchange' event allows pages that are currently using the > database to handle the change. The page can inspect the new version > number supplied by the 'versionchange' event, and if it knows that it > is compatible with a given upgrade, all it needs to do is to call > db.close() and then immediately reopen the database using > indexedDB.open(). The open call won't complete until the upgrade is > finished. > I had a question here: why does the page need to call 'close'?
