From ee40bb3706a059d070f250d83b7ea111116a0e44 Mon Sep 17 00:00:00 2001 From: Joshua Bell Date: Fri, 12 May 2017 09:41:12 -0700 Subject: [PATCH] Define db's associated upgrade tx to align with impls/tests (Resolves #192) Implementations and tests have create/deleteObjectStore throw "TransactionInactiveError" if the transaction has aborted but the abort event has not yet fired. The spec disagreed, or at least was imprecise about the definition of "finished". To resolve this, databases are given an associated upgrade tx which is nulled out when the event fires, rather than relying on "finished". This simplifies text elsewhere too. Covered by existing web-platform-tests. --- index.bs | 154 ++++++++++++---------- index.html | 366 ++++++++++++++++++++++++++++------------------------- 2 files changed, 280 insertions(+), 240 deletions(-) diff --git a/index.bs b/index.bs index 449b146..ce321f9 100644 --- a/index.bs +++ b/index.bs @@ -418,9 +418,12 @@ created, its [=database/version=] is 0 (zero). +A [=database=] has at most one associated upgrade transaction, +which is either null or an [=/upgrade transaction=], and is initially null. + @@ -484,7 +487,7 @@ connection=] with the [=/connection=] and with the |forced flag| set. A [=/connection=] has an object store set, which is initialized to the set of [=/object stores=] in the associated [=database=] when the [=/connection=] is created. The contents of the -set will remain constant except when an [=upgrade transaction=] is +set will remain constant except when an [=/upgrade transaction=] is running. A [=/connection=]'s [=get the parent=] algorithm returns @@ -508,7 +511,7 @@ storing data in a [=database=].
Each database has a set of [=/object stores=]. The set of [=/object -stores=] can be changed, but only using an [=upgrade transaction=], +stores=] can be changed, but only using an [=/upgrade transaction=], i.e. in response to an [=upgradeneeded=] event. When a new database is created it doesn't contain any [=/object stores=]. @@ -562,12 +565,12 @@ An [=/object store handle=] has an index set, which is initialized to the set of [=/indexes=] that reference the associated [=object-store-handle/object store=] when the [=/object store handle=] is created. The contents of the set will remain constant except when -an [=upgrade transaction=] is running. +an [=/upgrade transaction=] is running. An [=/object store handle=] has a name, which is initialized to the [=object-store/name=] of the associated [=object-store-handle/object store=] when the [=/object store handle=] -is created. The name will remain constant except when an [=upgrade +is created. The name will remain constant except when an [=/upgrade transaction=] is running.
@@ -916,7 +919,7 @@ particular [=/index=] within a [=/transaction=]. An [=index handle=] has a name, which is initialized to the [=index/name=] of the associated [=index-handle/index=] when the [=index handle=] is created. The name will remain constant except when -an [=upgrade transaction=] is running. +an [=/upgrade transaction=] is running. @@ -1196,7 +1199,7 @@ with [=transaction/cleanup event loop=] matching the current An upgrade transaction is a [=/transaction=] with [=transaction/mode=] {{"versionchange"}}. -An [=upgrade transaction=] is automatically created when running the +An [=/upgrade transaction=] is automatically created when running the steps to [=run an upgrade transaction=] after a [=/connection=] is opened to a [=/database=], if a [=database/version=] greater than the current [=database/version=] is specified. This [=/transaction=] @@ -1204,26 +1207,26 @@ will be active inside the [=upgradeneeded=] event handler. + a given database to be closed before continuing.

5.3. Deleting a database

The steps to delete a database are as follows. The algorithm in these steps takes three arguments: the origin that -requested the database to be deleted, a database name, and a request.

+requested the database to be deleted, a database name, and a request.

  1. Let queue be the connection queue for origin and name.

    @@ -5284,7 +5286,7 @@

    Wait until all previous requests in queue have been processed.

  2. -

    Let db be the database named name in origin, if one exists. Otherwise, return 0 (zero).

    +

    Let db be the database named name in origin, if one exists. Otherwise, return 0 (zero).

  3. Let openConnections be the set of all connections associated with db.

  4. @@ -5315,16 +5317,18 @@

    transaction to commit.

    1. -

      All the changes made to the database by transaction are -written to the database.

      +

      All the changes made to the database by transaction are +written to the database.

    2. -

      If an error occurs while writing the changes to the database, abort the transaction by following the steps +

      If an error occurs while writing the changes to the database, abort the transaction by following the steps to abort a transaction with transaction and an appropriate for the error, for example "QuotaExceededError" or "UnknownError" DOMException.

    3. Queue a task to run these steps:

        +
      1. +

        If transaction is an upgrade transaction, set the database's upgrade transaction to null.

      2. Fire an event named complete at transaction.

      3. Let old version be db’s version.

      4. @@ -5488,24 +5496,24 @@

        with the error property set to a newly created "AbortError" DOMException.

    4. -

      Wait for transaction to finish.

      +

      Wait for transaction to finish.

      + include steps specific to upgrade transactions.

5.8. Aborting an upgrade transaction

The steps to abort an upgrade transaction with transaction are as follows.

  1. Let connection be transaction’s connection.

  2. -

    Let database be connection’s database.

    +

    Let database be connection’s database.

  3. Set connection’s version to database’s version if database previously existed, or 0 (zero) if database was newly created.

    @@ -5551,8 +5559,8 @@

+ not modified, even if the aborted upgrade transaction was + creating a new database.

5.9. Firing a success event

To fire a success event at a request, @@ -5625,7 +5633,7 @@

6. Database operations

-

This section describes various operations done on the data in object stores and indexes in a database. +

This section describes various operations done on the data in object stores and indexes in a database. These operations are run by the steps to asynchronously execute a request.