Question

I’m trying to create a bookmark extension in Chrome and I want to leverage WebSQL to store all kind of information about bookmarks locally. Here’s what I’ve done so far:

(function() {
  var Home,
    __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; };

  window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem;

  Home = (function() {

    function Home() {
      this.onDBInit = __bind(this.onDBInit, this);      this.db = openDatabase("Journal", "", "Bookmarks Stats", 5 * 1024 * 1024, this.onDBInit, this.onDBError);
    }

    Home.prototype.onDBInit = function(db) {
      console.log(db.version);
      db.changeVersion("", "1.0", this.initDB, this.onDBError);
      return console.log(db);
    };

    Home.prototype.initDB = function(t) {
      console.log(t);
      return t.executeSql('CREATE TABLE bookmarks (id, title, url)');
    };

    Home.prototype.onDBError = function(e) {
      return console.log(e);
    };

    return Home;

  })();

  window.Registerable(Home);

}).call(this);

For some reason, changeVersion ALWAYS fails. I have tried to delete the database, restart chrome, etc. Chrome version: 18.

Answer 1

In my limited experience, changeVersion does work on Chrome. I’ve also read complaints here about it not working properly on Safari, but it does.

However, there are two catches:

Catch 1:

Often, changeVersion appears to fail (it gives an error and db.version will still return the old value), but the transaction callback will fire and when you re-open the web page and its database, the version number will be correct.

Catch 2:

It seems you must supply precisely five arguments, including three callbacks. If you don’t supply these five arguments, for example you only do the first three, then the current version will remain unchanged. So if you were to follow the instruction in this tutorial that everyone’s referring to, you would be disappointed.

This is the case for Chrome and Safari on Windows.

Arguments are:
1: expected version
2: new version
3: transaction callback (you can execute SQL here as part of the version change)
4: failure callback (if version change or transaction callback failed)
5: succes callback (if version change and transaction callback succeeded)

I haven’t tested this on iOS devices but it matches the Safari specifications provided here:
https://developer.apple.com/library/safari/#documentation/iphone/conceptual/safarijsdatabaseguide/usingthejavascriptdatabase/usingthejavascriptdatabase.html

In Opera, changeVersion waits with setting db.version to its new value until after you’ve executed an actual sql transaction using executeSql. So I use a SELECT statement that has no further consequence. This does not actually have to be inside the transaction callback: I discovered it when I tried a separate executeSql statement in the browser console after trying a whole bunch of changeVersion commands.