spec/Overview.html 1.1778 2607 SQL: Split the transaction() method into

SQL: Split the transaction() method into two, one for read/write access
and one for shared read access. (whatwg r2607)

changeVersion()
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#dom-database-changeversion
expected version
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#concept-database-expected-version
Database
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#database
transaction()
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#dom-database-transaction
openDatabase()
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#dom-opendatabase
5.10.2.6 Processing model
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#processing-model-3
5.10.2.3 Executing SQL statements
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#executing-sql-statements
If the mode is read-only but the statement's main verb can modify the database, jump to the "in case of error" steps below. Only the statement's main verb (e.g. UPDATE, SELECT, DROP) is considered here. Thus, a statement like "UPDATE test SET id=0 WHERE 0=1" would be treated as potentially modifying the database for the purposes of this step, even though it could never in fact have any side-effects.
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#modifications-fail-if-read-only
ObjectArray
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#objectarray
readTransaction()
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#dom-database-readtransaction
SQLTransactionErrorCallback
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#sqltransactionerrorcallback
version
http://people.w3.org/mike/diffs/html5/spec/Overview.1.1778.html#dom-database-version

http://people.w3.org/mike/diffs/html5/spec/Overview.diff.html
http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.1777&r2=1.1778&f=h
http://html5.org/tools/web-apps-tracker?from=2606&to=2607

===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.1777
retrieving revision 1.1778
diff -u -d -r1.1777 -r1.1778
--- Overview.html 29 Dec 2008 09:14:38 -0000 1.1777
+++ Overview.html 29 Dec 2008 09:59:51 -0000 1.1778
@@ -31779,9 +31779,8 @@
   will try to use hundreds of megabytes to declare this upfront,
   instead of the user agent prompting the user for permission to
   increase the quota every five megabytes.<pre class=idl>interface <dfn id=database>Database</dfn> {
-  void <a href=#dom-database-transaction title=dom-database-transaction>transaction</a>(in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback);
-  void <a href=#dom-database-transaction title=dom-database-transaction>transaction</a>(in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback, in <a href=#sqltransactionerrorcallback>SQLTransactionErrorCallback</a> errorCallback);
-  void <a href=#dom-database-transaction title=dom-database-transaction>transaction</a>(in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback, in <a href=#sqltransactionerrorcallback>SQLTransactionErrorCallback</a> errorCallback, in <a href=#voidcallback>VoidCallback</a> successCallback);
+  void <a href=#dom-database-transaction title=dom-database-transaction>transaction</a>(in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback, [Optional] in <a href=#sqltransactionerrorcallback>SQLTransactionErrorCallback</a> errorCallback, [Optional] in <a href=#voidcallback>VoidCallback</a> successCallback);
+  void <a href=#dom-database-readtransaction title=dom-database-readTransaction>readTransaction</a>(in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback, [Optional] in <a href=#sqltransactionerrorcallback>SQLTransactionErrorCallback</a> errorCallback, [Optional] in <a href=#voidcallback>VoidCallback</a> successCallback);
 
   readonly attribute DOMString <a href=#dom-database-version title=dom-database-version>version</a>;
   void <a href=#dom-database-changeversion title=dom-database-changeVersion>changeVersion</a>(in DOMString oldVersion, in DOMString newVersion, in <a href=#sqltransactioncallback>SQLTransactionCallback</a> callback, in <a href=#sqltransactionerrorcallback>SQLTransactionErrorCallback</a> errorCallback, in <a href=#voidcallback>VoidCallback</a> successCallback);
@@ -31794,13 +31793,16 @@
 interface <dfn id=sqltransactionerrorcallback>SQLTransactionErrorCallback</dfn> {
   void <span title=dom-sqltransactionerrorcallback-handleEvent>handleEvent</span>(in <a href=#sqlerror>SQLError</a> error);
 };</pre><p>The <dfn id=dom-database-transaction title=dom-database-transaction><code>transaction()</code></dfn>
-  method takes one or two arguments. When called, the method must
+  and <dfn id=dom-database-readtransaction title=dom-database-readTransaction><code>readTransaction()</code></dfn>
+  methods takes one to three arguments. When called, these method must
   immediately return and then asynchronously run the <a href=#transaction-steps>transaction
   steps</a> with the <i>transaction callback</i> being the first
   argument, the <i>error callback</i> being the second argument, if
   any, the <i>success callback</i> being the third argument, if any,
   and with no <i>preflight operation</i> or <i>postflight
-  operation</i>.<p>The version that the database was opened with is the <dfn id=concept-database-expected-version title=concept-database-expected-version>expected version</dfn> of
+  operation</i>.<p>For the <code title=dom-database-transaction><a href=#dom-database-transaction>transaction()</a></code> method, the
+  <i>mode</i> must be read/write. For the <code title=dom-database-readTransaction><a href=#dom-database-readtransaction>readTransaction()</a></code>
+  method, the <i>mode</i> must be read-only.<p>The version that the database was opened with is the <dfn id=concept-database-expected-version title=concept-database-expected-version>expected version</dfn> of
   this <code><a href=#database>Database</a></code> object. It can be the empty string, in
   which case there is no expected version &mdash; any version is
   fine.<p>On getting, the <dfn id=dom-database-version title=dom-database-version><code>version</code></dfn> attribute
@@ -31818,7 +31820,7 @@
    exactly matches the database's actual version. If it does not, then
    the <i>preflight operation</i> fails.</li>
 
-  </ol><p>...and the <i>postflight operation</i> being the following:<ol><li>Change the database's actual version to the value of the second
+  </ol><p>...the <i>postflight operation</i> being the following:<ol><li>Change the database's actual version to the value of the second
    argument to the <code title=dom-database-changeVersion><a href=#dom-database-changeversion>changeVersion()</a></code>
    method.</li>
 
@@ -31826,7 +31828,7 @@
    the value of the second argument to the <code title=dom-database-changeVersion><a href=#dom-database-changeversion>changeVersion()</a></code>
    method.</li>
 
-  </ol><h5 id=executing-sql-statements><span class=secno>5.10.2.3 </span>Executing SQL statements</h5><p>The <code title=dom-database-transaction><a href=#dom-database-transaction>transaction()</a></code>
+  </ol><p>...and the <i>mode</i> being read/write.<h5 id=executing-sql-statements><span class=secno>5.10.2.3 </span>Executing SQL statements</h5><p>The <code title=dom-database-transaction><a href=#dom-database-transaction>transaction()</a></code>
   and <code title=dom-database-changeVersion><a href=#dom-database-changeversion>changeVersion()</a></code>
   methods invoke callbacks with <code><a href=#sqltransaction>SQLTransaction</a></code>
   objects.<pre class=idl>typedef sequence&lt;any&gt; <dfn id=objectarray>ObjectArray</dfn>;
@@ -32006,12 +32008,18 @@
   be run asynchronously. These steps are invoked with a <i>transaction
   callback</i>, optionally an <i>error callback</i>, optionally a
   <i>success callback</i>, optionally a <i>preflight operation</i>,
-  and optionally a <i>postflight operation</i>.<ol><li><p>Open a new SQL transaction to the database, and create a
+  optionally a <i>postflight operation</i>, and with a <i>mode</i>
+  that is either read/write or read-only.<ol><li><p>Open a new SQL transaction to the database, and create a
    <code><a href=#sqltransaction>SQLTransaction</a></code> object that represents that
-   transaction.</li>
+   transaction. If the <i>mode</i> is read/write, the transaction must
+   have an exclusive write lock over the entire database. If the
+   <i>mode</i> is read-only, the transaction must have a shared read
+   lock over the entire database. The user agent should wait for an
+   appropriate lock to be available..</li>
 
-   <li><p>If an error occurred in the opening of the transaction, jump
-   to the last step.</li>
+   <li><p>If an error occurred in the opening of the transaction
+   (e.g. if the user agent failed to obtain an appropriate lock after
+   an appropriate delay), jump to the last step.</li>
 
    <li><p>If a <i>preflight operation</i> was defined for this
    instance of the transaction steps, run that. If it fails, then jump
@@ -32040,6 +32048,20 @@
     <ol><li><p>If the statement is marked as bogus, jump to the "in case
      of error" steps below.</li>
 
+     <li id=modifications-fail-if-read-only>
+
+      <p>If the <i>mode</i> is read-only but the statement's main verb
+      can modify the database, jump to the "in case of error" steps
+      below.</p>
+
+      <p class=note>Only the statement's main verb (e.g. <code title="">UPDATE</code>, <code title="">SELECT</code>, <code title="">DROP</code>) is considered here. Thus, a statement like
+      "<code title="">UPDATE test SET id=0 WHERE 0=1</code>" would be
+      treated as potentially modifying the database for the purposes
+      of this step, even though it could never in fact have any
+      side-effects.</p>
+
+     </li>
+
      <li><p>Execute the statement in the context of the transaction.
      <a href=#references>[SQL]</a></p>

Received on Monday, 29 December 2008 10:03:35 UTC