[IndexedDB] add dataLossMessage field to upgradeneeded event

2013-10-07 Thread David Grogan 
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

Re: [IndexedDB] Inform script of corruption recovery

2013-06-14 Thread David Grogan 
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

Re: [IndexedDB] Inform script of corruption recovery

2013-05-09 Thread David Grogan 
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

2013-05-09 Thread David Grogan 
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

2013-02-12 Thread David Grogan 
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] blocked event could be an error

2012-10-01 Thread David Grogan 
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] blocked event could be an error

2012-07-26 Thread David Grogan 
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: What happens when versionchange transaction is aborted?

2012-03-02 Thread David Grogan 
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] Implicit Transaction Request associated with failed transactions

2011-11-08 Thread David Grogan 
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

2011-11-08 Thread David Grogan 
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] Implicit Transaction Request associated with failed transactions

2011-10-05 Thread David Grogan 
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] Transaction Auto-Commit

2011-08-19 Thread David Grogan 
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] Evictable stores

2011-06-07 Thread David Grogan 
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: [Bug 11348] New: [IndexedDB] Overhaul of the event model

2011-02-15 Thread David Grogan 
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

2011-02-15 Thread David Grogan 
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