Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org wrote: What's the current thinking in terms of events that we're firing? I remember we talked about this a bit, but I don't remember the conclusion and I can't find it captured anywhere. Here's a brain dump of the requirements as I remember them: * Everything should have a source attribute. * Everything done in the context of a transaction should have a transaction attribute. (Probably even errors, which I believe is not the current case.) * Only success events should have a result. * Only error events should have a code and a messageor should they just have an error attribute which holds an IDBDatabaseError object? (If it's the former, then do we even need an interface for IDBDatabaseError to be defined?) * IIRC, Jonas suggested at some point that maybe there should be additional attributes beyond just the source and/or objects should link to their parents. (The latter probably makes the most sense, right? If so, I'll bug it.) Is there anything I'm missing? As far as I can tell, this means we need 5 events: an IDBEvent (with source) and then error with transaction, error without, success with, and success without. That seems kind of ugly though. Another possibility is that we could put a transaction attribute on IDBEvent that's null when there's no transaction. And then error and success would have their own subclasses. To me, this sounds best. Thoughts? Actually, I was proposing something entirely different. IDBRequest should look like this: interface IDBRequest : EventTarget { For each, what do we do when it's not available? Throw exception? Return undefined? Null? Particularly in the errorCode case, it's not clear to me what the right thing to do is. How do IDBVersionChangeEvent and its version attribute fit in to this new model? Should we add a nullable version attribute to IDBRequest and let the function handling a blocked event check event.target.version? Could we add a version attribute just to IDBVersionChangeRequest? attribute any result; attribute unsigned long errorCode; attribute DOMObject source; attribute IDBTransaction transaction; const unsigned short LOADING = 1; const unsigned short DONE = 2; readonly attribute unsigned short readyState; attribute Function onsuccess; attribute Function onerror; }; success and error events are plain Event objects, i.e. no indexedDB-specific properties. The advantage of this is: 1. Request objects are actually useful as representing the request. Consumers of a request can check what the readystate is and either get the .result or attach a event listener as appropriate. (As things stand now you can't really rely on .readyState. The only thing it tells you is if you got to the request too late or not. If you risk getting there too late you better rewrite your code) 2. Easier to implement a promises-style API on top of indexedDB. 3. More similar to for example XMLHttpRequest The downside is: 1. Have to use a bigger syntax to get to the result. event.result vs. event.target.result. / Jonas
Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model
On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org wrote: On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org wrote: What's the current thinking in terms of events that we're firing? I remember we talked about this a bit, but I don't remember the conclusion and I can't find it captured anywhere. Here's a brain dump of the requirements as I remember them: * Everything should have a source attribute. * Everything done in the context of a transaction should have a transaction attribute. (Probably even errors, which I believe is not the current case.) * Only success events should have a result. * Only error events should have a code and a messageor should they just have an error attribute which holds an IDBDatabaseError object? (If it's the former, then do we even need an interface for IDBDatabaseError to be defined?) * IIRC, Jonas suggested at some point that maybe there should be additional attributes beyond just the source and/or objects should link to their parents. (The latter probably makes the most sense, right? If so, I'll bug it.) Is there anything I'm missing? As far as I can tell, this means we need 5 events: an IDBEvent (with source) and then error with transaction, error without, success with, and success without. That seems kind of ugly though. Another possibility is that we could put a transaction attribute on IDBEvent that's null when there's no transaction. And then error and success would have their own subclasses. To me, this sounds best. Thoughts? Actually, I was proposing something entirely different. IDBRequest should look like this: interface IDBRequest : EventTarget { For each, what do we do when it's not available? Throw exception? Return undefined? Null? Particularly in the errorCode case, it's not clear to me what the right thing to do is. How do IDBVersionChangeEvent and its version attribute fit in to this new model? Should we add a nullable version attribute to IDBRequest and let the function handling a blocked event check event.target.version? Could we add a version attribute just to IDBVersionChangeRequest? Adding a newVersion, nextVersion, or something similar to IDBVersionChangeRequest seems like the best answer to me. Simply adding version to it seems kind of confusing though. Adding it to the request won't help as the versionchange event is fired at other databases, not at the request. It's fired at the request if the version_change transaction is blocked because other connections to the database remain open after receiving versionchange events, but I see what you mean. Adding it to the request is also not needed since the new version isn't something that is the result of the request, it's something you specify when creating the request. I think we can leave IDBVersionChangeEvent as it is, it's an entirely different beast from success/error. I'm on board with this. / Jonas
Re: [IndexedDB] Evictable stores
We (chrome) are still having internal discussions about evictable vs non-evictable storage; we're on board with worrying about this in v2. On Tue, May 31, 2011 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, May 31, 2011 at 3:46 PM, Pablo Castro pablo.cas...@microsoft.com wrote: We discussed evictable stores some time ago and captured it in bug 11350 [1], but I haven't seen further discussion on it and it hasn't gone into the spec. I'm curious on where folks are with this? Should we move it to v2? Should we just allow UAs to have their own policy around eviction (back at TPAC it seemed folks had reasonable but different strategies for handling when to allow websites to use storage already). I think this is a very interesting feature, but one that I'd prefer to move to a version 2 as it isn't a required feature and is one that seems easy to retrofit. / Jonas
Re: [IndexedDB] Transaction Auto-Commit
On Tue, Aug 16, 2011 at 10:52 AM, Israel Hilerio isra...@microsoft.comwrote: On Thursday, August 04, 2011 11:02 AM, Jonas Sicking wrote: [snip] I'd be open to allowing read transactions which are started after a write transaction to see the before-write database contents. Would definitely want input from Microsoft and Google first though. There is also a question if this should be opt-in or default behavior. My gut feeling is to leave this for version 2. Though that of course removes the ability to make it default behaviour. Microsoft would like to push this change to v2 and try to get the v1 spec to Last Call soon so we can start getting some adoption on this technology. If this change were incorporated into the spec, our current implementations would still conform, correct? Allowing read transactions to start before a read_write transaction is finished seems to give browsers the choice of implementing an optimization without invalidating current behavior. That said, we (chromium) wouldn't implement such an optimization for quite a while, so when it goes into the spec is not of much practical importance.
Re: [indexeddb] Implicit Transaction Request associated with failed transactions
On Tue, Oct 4, 2011 at 3:01 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio isra...@microsoft.com wrote: Based on previous conversations, it seems we've agreed that there are situations in which a transaction could failed independent of explicit requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be represented as an implicit request that is being triggered by a transaction. We would like to add this concept to the spec. The benefit of doing this is that it will allow developers to detect the error code associated with a direct transaction failure. This is how we see the concept being used: trans.onerror = function (e) { //eventTarget is mapped to an implicit transaction that was created behind the scenes to track the transaction if (e.eventTarget.errorCode === TIMEOUT_ERR) { // you know the transaction error because of a timeout problem } else if (e.eventTarget.errorCode === TIMEOUT_ERR) { // you know the transaction error because of a quota problem } } Our assumption is that the error came not from an explicit request but from the transaction itself. The way it is today, the e.eventTarget will not exists (will be undefined) because the error was not generated from an explicit request. Today, eventTargets are only populated from explicit requests. Good catch! We had a long thread about this a while back with the subject [IndexedDB] Reason for aborting transactions. But it seems to have fizzled with no real conclusion as to changing the spec. In part that seems to have been my fault pushing back at exposing the reason for a aborted transaction. I think I was wrong :-) I think I would prefer adding a .errorCode on IDBTransaction through (or .errorName or .error or whatever we'll end up changing it to). This seems more clear than creating a implicit request object. It'll also make it easy to find the error if you're outside the error handler. With the implicit request, you have no way of getting to the request, and thus the error code, from code outside the error handler, such from code that looks at the transaction after it has run. And the code above would work exactly as is! Let me know what you think? In detail, here is what I suggest: 1. Add a .errorCode (or .errorName/.error) property on IDBTransaction/IDBTransactionSync. 2. The property default to 0 (or empty string/null) 3. In the Steps for aborting a transaction add a new step between the current steps 1 and 2 which says something like set the errorCode property of vartransaction/var to varcode/var. This way the reason for the abort is available (through the transaction) while firing he error event on all still pending requests in step 2. The reason is also available while firing the abort event on the transaction itself. LGTM. We had discussed how to notify the script that a transaction aborted due to quota during the commit, after all the operations' success handlers had been called; an errorCode on IDBTransaction is what we were leaning toward. / Jonas
Re: [indexeddb] Implicit Transaction Request associated with failed transactions
On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio isra...@microsoft.comwrote: On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote: On Thu, Oct 13, 2011 at 10:57 AM, Israel Hilerio isra...@microsoft.com wrote: On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote: On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote: On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio isra...@microsoft.com wrote: Based on previous conversations, it seems we've agreed that there are situations in which a transaction could failed independent of explicit requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be represented as an implicit request that is being triggered by a transaction. We would like to add this concept to the spec. The benefit of doing this is that it will allow developers to detect the error code associated with a direct transaction failure. This is how we see the concept being used: trans.onerror = function (e) { //eventTarget is mapped to an implicit transaction that was created behind the scenes to track the transaction if (e.eventTarget.errorCode === TIMEOUT_ERR) { // you know the transaction error because of a timeout problem } else if (e.eventTarget.errorCode === TIMEOUT_ERR) { // you know the transaction error because of a quota problem } } Our assumption is that the error came not from an explicit request but from the transaction itself. The way it is today, the e.eventTarget will not exists (will be undefined) because the error was not generated from an explicit request. Today, eventTargets are only populated from explicit requests. Good catch! We had a long thread about this a while back with the subject [IndexedDB] Reason for aborting transactions. But it seems to have fizzled with no real conclusion as to changing the spec. In part that seems to have been my fault pushing back at exposing the reason for a aborted transaction. I think I was wrong :-) I think I would prefer adding a .errorCode on IDBTransaction through (or .errorName or .error or whatever we'll end up changing it to). This seems more clear than creating a implicit request object. It'll also make it easy to find the error if you're outside the error handler. With the implicit request, you have no way of getting to the request, and thus the error code, from code outside the error handler, such from code that looks at the transaction after it has run. And the code above would work exactly as is! Let me know what you think? In detail, here is what I suggest: 1. Add a .errorCode (or .errorName/.error) property on IDBTransaction/IDBTransactionSync. 2. The property default to 0 (or empty string/null) 3. In the Steps for aborting a transaction add a new step between the current steps 1 and 2 which says something like set the errorCode property of vartransaction/var to varcode/var. This way the reason for the abort is available (through the transaction) while firing the error event on all still pending requests in step 2. The reason is also available while firing the abort event on the transaction itself. / Jonas Independent on how we handler error, we like this approach! This is our interpretation of the impact it will have on the overall feature. SCENARIO #1: Whenever there is an error on a request, the error value associated with the request will be assigned to the transaction error value. The error value in the transaction will be available on the IDBTransaction.onerror and IDBTransaction.onabort handlers. SCENARIO #2: Whenever there is an error associated with the transaction (e.g. QUOTA or TIMEOUT ), the error value associated with the failure (e.g. QUOTA or TIMEOUT) will be assigned to the transaction error value. The error value in the transaction will be available on the IDBTransaction.onerror and IDBTransaction.onabort handlers. SCENARIO #3: A developer uses the IDBTransaction.abort() method to cancel the transaction. No error will be assigned to the transaction error value. The error value will be 0 (or empty string/null) when the IDBTransaction.onabort handler is called. SCENARIO #4 (to be complete): Whenever there is an error on a request, the error value associated with the request will be assigned to the transaction error value. However, if the event.preventDefault() method is called on the request, the only handler that will be called will be IDBTransaction.onerror and
Re: [indexeddb] Implicit Transaction Request associated with failed transactions
On Tue, Nov 8, 2011 at 4:54 PM, Israel Hilerio isra...@microsoft.comwrote: On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote: On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio isra...@microsoft.com wrote: On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote: The firing of error events on the transaction should only be of two types: propagation error events or transaction error events. This should allow devs the ability to handle data error objects inside their IDBRequest.onerror handler and transaction commit error on their IDBTransaction.onerror handler. The only difference is that QuotaError and TimeoutError would wouldn't be cancellable and will always bubble. Not quite sure what you mean by propagation error events. Do you mean events that are fired on a request, but where the transaction.onerror handler is called during the event's bubble phase? If so I think this sounds good. However there's still the matter of defining when a transaction error event should be fired. Transactions currently fail to commit in at least the following circumstances: Yes, by propagation error events I meant events that are fired on a request, but where the transaction.onerror handler is called during the event's bubble phase. A) When transaction.abort() is explicitly called B) When a .put or .add request fails due to a 'unique' constraint violation in an index, and the result error event *isn't* canceled using event.preventDefault() C) When an exception is thrown during a event handler for a error event D) When an exception is thrown during a event handler for a success event E) When a index is created with a 'unique' constraint on an objectStore which already has data which violates the constraint. F) When a request fails due to database error (for example IO error) and the resulting error event *isn't* canceled using event.preventDefault() G) When a transaction fails to commit due to a quota error H) When a transaction fails to commit due to a IO error I) When a transaction fails to commit due to a timeout error Great list :-) I've probably missed some places too. In which of these occasions do you think we should fire an error event on the transaction before firing the abort event? And note that in *all* of the above cases we will fire a abort event on the transaction. From the discussion so far, it sounds like you *don't* want to fire an error event for at least for situation A, which makes sense to me. Whatever situations we decide to fire an error event in, I'd like there to be some sort of consistency. I'd also like to start by looking at use cases rather than just at random pick situations that seem good. So, if anyone think we should fire error events targeted at the transaction in any of the above situations, please state use cases, and which of the above situations you think should generate an error event. Additionally, I'm not sure that we need to worry about I) above. I) only happens when there are timeouts specified, which only is possible in the synchronous API. But in the synchronous API we never fire any events, but simply let IDBDatabaseSync.transaction throw an exception. / Jonas I believe that error events on the transaction should be fired for individual request related issues: B) When a .put or .add request fails due to a 'unique' constraint violation in an index, and the result error event *isn't* canceled using event.preventDefault() C) When an exception is thrown during an event handler for a error event D) When an exception is thrown during an event handler for a success event E) When an index is created with a 'unique' constraint on an objectStore which already has data which violates the constraint. F) When a request fails due to database error (for example IO error) and the resulting error event *isn't* canceled using event.preventDefault() However, I don't believe we should fire error events on the transaction for transaction related issues: G) When a transaction fails to commit due to a quota error H) When a transaction fails to commit due to a IO error My fundamental argument is that these are two different types of error cases, request and fatal errors. I believe that developers want to handle request errors because they can do something about them. These request errors are reflections of problems related to individual requests (i.e. add, put, delete record issues or schema related issues). Preventing their default behavior will allow devs to add 99 records into the db but ignore the last 1 record that failed without having to restart the transaction. On the other hand, fatal errors are different. They are associated with a backend problem that is not necessarily a reflection of a single request problem but a larger db issue. The developer was adding 100 records and they ran out of space
Re: IndexedDB: What happens when versionchange transaction is aborted?
On Fri, Mar 2, 2012 at 10:33 AM, Israel Hilerio isra...@microsoft.comwrote: On Friday, March 02, 2012 7:27 AM, Jonas Sicking wrote: On Fri, Mar 2, 2012 at 4:35 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, While editing the spec just now I came across something that I didn't quite understand. In section 4.8 versionchange transaction steps step 9 says: If for any reason the versionchange transaction is aborted while in the onupgradeneeded event handler while the database is being created for the first time, the database will remain in the system with the default attributes. If the transaction is aborted and there is an existing database, the values remain unchanged. The default attributes for the IDBDatabase are: And then has a table. My recollection was that this text was added as a result of discussions of what the IDBDatabase.objectStoreNames/version/name properties should return after a versionchange transaction is aborted. However the text is ambiguous in a few ways which makes me not sure what to do in the Firefox implementation. First of all, the text seems to use the word database to mean two different things. In the database is being created for the first time I think database is intended to refer to the on-disk database file. In the database will remain in the system I think database intends to refer to the in-memory IDBDatabase instance. Or is the text really intending to say that we should keep the on-disk database file even if the transaction which creates the database is aborted? As I recall, we had talked about keeping the initial DB version (i.e. 0) even if the versionchange transaction was aborted [1]. The reason was that a version of 0 is something that can only be generated internally and would signal the initial creation state of the db. However, we didn't want to store any more information about the db at that point because the transaction was cancelled. This enabled us to reject the developer changes but keep the internal processing. This would allow developers to retry their transactions with a version of 1 and not have any side effects. Second, it seems to treat newly created databases different from ones that are upgraded. It says that newly created database should get their default value, with version set to 0 and objectStoreNames being null. In other words it calls for these properties to be reverted to the value they had before the versionchange event fired. However existing database should remain unchanged which I interpret to mean that they should retain the value they had at the time when the transaction was aborted. The intent was to ensure that db versionchange transactions on new or existing dbs would retain their pre-transaction state [1]. That was the reason, we defined the table to capture the pre-transaction state of non-existent dbs. This was an intent to keep them consistent. I really don't care that much what behavior we have here since it's unlikely that anyone is going to look at these properties after a versionchange transaction is aborted and thus the open request fails. But I think we should be consistent and treat newly opened databases the same as we treat newly upgraded databases. In both situations we can one of the following: 1. Revert properties to the value they had when the version-change transaction started I like this one [1]. This approach allows the same version to be reused in the correct/intended way. +1 to each of Israel's responses about the 5 proposals. 2. Revert properties to the value they had when the right after the version-change transaction started (i.e. only the .version property is changed) I believe this approach would prevent the same version from being used in the correct/intended way. 3. Keep properties as they were when the transaction was aborted (this is what we do for close()) I believe having residual values could lead to potential side effects. I like it better to not have any residual information from the failed transaction. 4. Make properties throw 5. Make properties return null I believe there are some tooling scenarios in which it might be useful to access the properties. Also, technically objectStoreNames starts out as an empty list, not null as the table currently claims. But we can of course still revert it to null if we go with option 1 or 2. I would like for us to choose option 1 and therefore, null seems reasonable. If it starts out as an empty list, why would we change it to null? Either way, no strong opinion here. I don't really care which option we choose though 4 and 5 sounds annoying for users and doesn't seem any easier to implement. I'd personally lean towards 3. It seems like the current text is aiming for 1 or 3 but I can't say with certainty. I
Re: [IndexedDB] blocked event could be an error
On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal odi...@opera.comwrote: There are some open issues in the spec that has been there a long time. They deal with opening and deleting database. http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/** Overview.html#dfn-steps-for-**deleting-a-databasehttp://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database # 7. Wait until all objects in openDatabases are closed and all of their #transactions are finished. # #ISSUE: Should we allow blocked to be fired here too, if waiting takes #too long? # # 8. Delete db. http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/** Overview.html#dfn-steps-for-**running-a--versionchange--**transactionhttp://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction # 4. Wait until either all objects in openDatabases are closed and all of #their transactions are finished. # #ISSUE: If .close() is called immediately but a transaction associated # with the connection keeps running for a long time, should we # also fire a blocked event? # #ISSUE: If, while we're waiting here, someone calls open with a # version number higher than version, we should probably let # that upgrade run first and bail here if it was successful. To be very honest, the whole blocked and then wait-system seems very over the top for a small benefit. IMHO the harm is greater than any potential small benefit. We'd have to keep lots of requests indefinitely open. If the other page having an open database doesn't clean up and db.close() in its db.versionchange handler, most definitely the developer haven't ever thought about the case. I see no benefit in waiting for that to happen. And the page that is being blocked, also has no way to abort/close its own request if you were to follow spec because transaction is not set until after blocked has run(!). We've also received comments from internal development teams about this issue. The devs didn't like having an outstanding request that may or may not ever receive a success event. They planned on cancelling their open request if they got a blocked event but, as Odin points out, quickly discovered there was no way to do so. We've talked briefly about adding something like IndexedDB.openOrFail(db, high_version) that would fire a BlockedError if other open connections didn't close in response to versionchange events. So not only will the browser implementation sit around with a useless request (possible several as the page retries or the user opens up more windows) - but also the page itself can't be a good citizen and clean up for itself (well, as long as they forgot to close in versionchange). So in the case of being blocked, it would be nicer to have the new page open request (or delete) get an error event, maybe something like BlockedError. It can then show the user «Please close the other window and [retry]». Also, there's a much bigger chance of developers listening to error on the opening page, rather than blocked. +1. Replacing blocked event with an error event named BlockedError would be an improvement. As for what implementations do now, based on the very simple tests I did, Firefox seems to follow the spec as if it was written based on that implementation (:P) - IE10 doesn't send fire a versionchange request at all, but it does do blocked. So I guess IE would rather quickly run into compat problems. It does however fire the blocked event on the opening page, although it's not really useful for much as far as I can see. What do you think? PS: In *any* case, those issues should be resolved some way, I just think simplifying such a corner case would be very beneficial. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [IndexedDB] blocked event could be an error
On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. I don't know by what measure it's quite early or the right time. It'd be the right time because though IDB usage is picking up, it's still relatively low. Optimally this change would have been made a few months or years ago, but now is better than later. We've passed Last Call, there are 3 shipping implementations, all of which have considered their implementation complete enough to switch from prefixed implementations to unprefixed ones. They all implement the behavior that you are proposing to change. We'd be ok with changing this, our unprefixedness notwithstanding. I think the pain it would save developers down the road would make up for the immediate pain it would cause to both vendors and developers. But that's just a judgment call, I'm relying on intuition and obviously have no data about what the future will hold. To balance the concerns of open with complicated semantics and backward-compatibility, I propose that we add two methods to IDBFactory: openOrFail and openOrBlock. Most introductory IDB tutorials and examples would steer developers towards openOrFail. The current open method would be an alias for openOrBlock. That open's documentation would be [deprecated] alias for openOrBlock should give developers some pause about using it just because it has the simplest name. At least the Amazon cloud reader uses IndexedDB. I've started receiving enough questions about IDB that I would imagine that there are more websites deployed which uses it. / Jonas
Re: [IndexedDB] Inform script of corruption recovery
On Mon, Feb 11, 2013 at 2:55 PM, Kyle Huey m...@kylehuey.com wrote: On Mon, Feb 11, 2013 at 10:40 PM, David Grogan dgro...@chromium.orgwrote: When chrome opens an IDB database, it attempts to detect corruption. If the database appears to have been corrupted, either via software bug or hardware fault, chrome performs recovery. As currently implemented (we may try to do something more surgical in the future), recovery means removing all the origin's databases from disk and creating a new empty database. It would be useful to alert script that some data has been lost in this situation. The web app could then alert the user or take other appropriate action. This is important in offline editing scenarios, where this represents true user data loss rather than just a flush of a data cache. Do you expect to ever be able to implement something more granular than a per-database recover or discard? I would imagine that's as surgical as it is going to get. We've talked about checkpointing, which would allow chrome to recover everything except the last N commits. I think the answer to that question impacts how we design this. I'm assuming you mean because a surgical recovery could leave the version intact and make a new property on the upgradeneeded event inaccessible? In that case we could also put the property on the success event that comes in response to open().
Re: [IndexedDB] Inform script of corruption recovery
jsbell pointed out an annoyance with this approach. If we delete the entire backing store while opening a database, we can alert the page that that particular database was lost via the mechanism discussed in this thread. But if there are two databases lost then the opener of the second one is out of luck: when a request is made to open the second database, e.g. a day later, IDB won't know that it once existed so won't know to alert the page. Meaning that we can only provide this notification on a best-effort basis. On Mon, Feb 25, 2013 at 10:56 AM, Kyle Huey m...@kylehuey.com wrote: On Tue, Feb 12, 2013 at 1:49 PM, David Grogan dgro...@chromium.orgwrote: I think the answer to that question impacts how we design this. I'm assuming you mean because a surgical recovery could leave the version intact and make a new property on the upgradeneeded event inaccessible? In that case we could also put the property on the success event that comes in response to open(). Well I was thinking more like being able to recover one object store and not others. But this does raise an interesting question. If we can restore to the same db version, but not identical contents, how would we indicate that to the page? Is there anything more useful we can provide than someDataWasLost=true? Doesn't seem like it. Given that we can probably only provide a notification on a best-effort basis it would seem silly to try to provide a detailed message in those times where we did notify. - Kyle (Sorry for the delay responding, been on vacation).
Re: [IndexedDB] Inform script of corruption recovery
On Thu, May 9, 2013 at 4:01 PM, David Grogan dgro...@chromium.org wrote: jsbell pointed out an annoyance with this approach. If we delete the entire backing store while opening a database, we can alert the page that that particular database was lost via the mechanism discussed in this thread. To clarify, chromium stores all databases for an origin in a single leveldb instance, so this is a real possibility for us. But if there are two databases lost then the opener of the second one is out of luck: when a request is made to open the second database, e.g. a day later, IDB won't know that it once existed so won't know to alert the page. Meaning that we can only provide this notification on a best-effort basis. On Mon, Feb 25, 2013 at 10:56 AM, Kyle Huey m...@kylehuey.com wrote: On Tue, Feb 12, 2013 at 1:49 PM, David Grogan dgro...@chromium.orgwrote: I think the answer to that question impacts how we design this. I'm assuming you mean because a surgical recovery could leave the version intact and make a new property on the upgradeneeded event inaccessible? In that case we could also put the property on the success event that comes in response to open(). Well I was thinking more like being able to recover one object store and not others. But this does raise an interesting question. If we can restore to the same db version, but not identical contents, how would we indicate that to the page? Is there anything more useful we can provide than someDataWasLost=true? Doesn't seem like it. Given that we can probably only provide a notification on a best-effort basis it would seem silly to try to provide a detailed message in those times where we did notify. - Kyle (Sorry for the delay responding, been on vacation).
Re: [IndexedDB] Inform script of corruption recovery
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370 to track this. On Thu, May 9, 2013 at 6:01 PM, Kyle Huey m...@kylehuey.com wrote: On Thu, May 9, 2013 at 4:09 PM, David Grogan dgro...@chromium.org wrote: On Thu, May 9, 2013 at 4:01 PM, David Grogan dgro...@chromium.orgwrote: jsbell pointed out an annoyance with this approach. If we delete the entire backing store while opening a database, we can alert the page that that particular database was lost via the mechanism discussed in this thread. To clarify, chromium stores all databases for an origin in a single leveldb instance, so this is a real possibility for us. Yeah, I fear that giving anything remotely specific gets too far into implementation-detail land. - Kyle
[IndexedDB] add dataLossMessage field to upgradeneeded event
As discussed in [thread] we implemented a dataLoss field on the upgradeneeded event, tracked in [bug]. Following developer feedback on the implementation in Chrome, we'd like to add a complementary dataLossMessage field. The combination would act similarly to DOMException/DOMError's name and message fields. dataLoss provides something actionable to script (and the range of values will be well defined in a future iteration of the spec) and dataLossMessage provides a diagnostic message available for logging and to the script author during development. Some example messages would be missing files, log record too small, corrupted internal key, and partial record. In addition to being more transparent to web developers, this will allow developers to file better bugs against implementations. For example, Google Docs could log the messages and notice the upward trend of a specific error if a bug is introduced to the browser implementation. [thread] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0355.html [bug] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370