So that was one of the motives to add the creation callback on
openDatabase I presume.
In either case, before the script gets a Database object, a version check
needs to be made during openDatabase, so the value can be cached inside
the Database object, to be used for changeVersion, the version property
and subsequent transactions.
On Fri, 04 Sep 2009 03:06:37 +0200, Michael Nordman <[email protected]>
wrote:
If the version is stored in the database file itself, as is with webkit's
impl for example, the database object does not have immediate access to
that
value.
On Thu, Sep 3, 2009 at 5:57 PM, João Eiras <[email protected]> wrote:
Hi!
Database.changeVersion expects oldVersion and newVersion arguments. The
Database also specifies a version attribute.
The transaction steps tell to fail the transaction due to the failed
preflight condition if oldVersion does not match the current database
version.
Meanwhile, the callbacks have been made optional, and rightly so.
So:
- if the author does not use the callbacks, there no error reporting
that
the preflight condition failed
- the version check can be done synchronously when changeVersion is
called
because the Database object has immediate access to that value, and it's
much more convenient for the author to just get an exception (like
INVALID_STATE_ERR) than to have to go through the entire callback
process
just to realize later that the transaction failed due to the mismatched
version. It also spares the user agent from creating and executing a
transaction that WILL fail.
To solve these issues, I would suggest doing immediate synchronous
validation of the version when changeVersion is called, throwing an
exception on error, and drop that step from the preflight operations.
Thank you.
