IndexedDb and version, how can I tell the current db version?

[Ivo Pletikosic]

Hello all,

I am playing around with indexedDb and am finding that I cannot tell the version of the current DB.

After calling openDatabase() the db.version property  is always already set. I never see it blank after clearing out storage. or changing the db name to something random:

var request = context.indexedDB.open("TESTDB");

        request.onsuccess = function(event) {

            var db = event.target.result;

            console.log(db.version) //1

        }

If I pass an integer version as the second parameter to open() then db.version will reflect whatever I passed in.

I am using Chrome Version 24.0.1312.56 .

I see the same behavior when I step through the code at http://www.html5rocks.com/en/tutorials/indexeddb/todo/

How do I check the version so I know to use of setVesion or upgradeneeded  to build stores?

Many thanks,

- Ivo

[Joshua Bell]

On Fri, Jan 25, 2013 at 5:41 PM, Ivo Pletikosic <iplet...@gmail.com> wrote:

Hello all,

I am playing around with indexedDb and am finding that I cannot tell the version of the current DB.

After calling openDatabase() the db.version property  is always already set. I never see it blank after clearing out storage. or changing the db name to something random:

var request = context.indexedDB.open("TESTDB");

        request.onsuccess = function(event) {

            var db = event.target.result;

            console.log(db.version) //1

        }

If I pass an integer version as the second parameter to open() then db.version will reflect whatever I passed in.

That is expected behavior. The intended usage of the IndexedDB API is that you either open() with an explicit version (and your upgradeneeded handler is invoked as necessary) or you call open() with no version and either get the current version or the database is created for you at version 1 and your upgradeneeded handler is invoked.

There is no API for "does this database exist?". We have a nonstandard API in Chrome, indexedDB.webkitGetDatabaseNames() that can be used to enumerate databases, but it's primarily for debugging purposes. (Another tab could be creating a database while you're enumerating, so it's not considered reliable.)

 

I am using Chrome Version 24.0.1312.56 .

I see the same behavior when I step through the code at http://www.html5rocks.com/en/tutorials/indexeddb/todo/

How do I check the version so I know to use of setVesion or upgradeneeded  to build stores?

The setVersion API is obsolete and has been removed in 25. As of Chrome 23 it is not needed. 

The normal usage pattern is:

var dbName = "my-db";

var dbVersion = 2; // Increment this whenever your schema changes.

var request = indexedDB.open(dbName, dbVersion);

request.onupgradeneeded = function(e) {

  // If this is called, then the database was not already at 

  // the desired version so we need to upgrade.

  var db = request.result;

  if (e.oldVersion < 1) {

    db.createObjectStore("store1");

    db.createObjectStore("store2");

  }

  if (e.oldVersion < 2) {

    var store1 = request.transaction.objectStore("store1");

    store1.createIndex("index1", "keyPath");

    db.deleteObjectStore("store2");

    db.createObjectStore("store3");

  }

  // etc. for version < 3, 4...

};

request.onsuccess = function() {

  // When this is called, we know the database is at the desired version.

  var db = request.result;

  // Rest of your application logic here.

}; 

Many thanks,

- Ivo

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-html5/-/k_4Ev9e6YhwJ.
To post to this group, send email to chromiu...@chromium.org.
To unsubscribe from this group, send email to chromium-html...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.

[Aaron Shafovaloff]

There seems to be a nasty bug in Chrome 26 (stable) and 29 (canary) which prevents one from upgrading the database after having opened the database without a specified version. In other words, if I do:

var request = context.indexedDB.open("TESTDB");

I can't inspect for the current version and then:

var request = context.indexedDB.open("TESTDB",version + 1);

Hopefully this will get fixed soon. It seemingly prevents wrapper libraries from doing automatic version incrementing upon schema/structure changes.

[Aaron Shafovaloff]

OK, I'm back. This seems to be more fickle than I reported. Not hard to reproduce, but hard to find a concrete cause.

--
You received this message because you are subscribed to a topic in the Google Groups "Chromium HTML5" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-html5/0rfvwVdSlAs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to chromium-html...@chromium.org.

To post to this group, send email to chromiu...@chromium.org.

Visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.
 
 

[Ivo]

It has been 100% reproducible for me. Im surprised no one else has
mentioned it since Jan when I first asked about it. Had to drop
indexeddb support for the time being.

[Aaron Shafovaloff]

Ivo, please leave a comment here:

https://code.google.com/p/chromium/issues/detail?id=242115&can=4&q=indexeddb&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

.. and corroborate with me on the problem.

On Friday, January 25, 2013 6:41:50 PM UTC-7, Ivo Pletikosic wrote:

[Marius Kjeldahl]

I've struggeled with IndexedDB for more than a year. It's completely unusable unless you have a very simple use-case (static really simple schema). Considering bugs are being fixed at glacial speed and even simple test-cases crash by simple bashing the reload button a few times (locking up the database completely), I believe there simply is no client side database like storage solution (localStorage does not cut it either, although that may at least be more stable).

I simply gave up trying to write browser based SPA applications; if it runs in the browser, it needs a server, and on phone/tablets you need to use the native solutions (sqlite on Android for instance).

Thanks,

Marius K.

[Joshua Bell]

On Mon, May 20, 2013 at 11:05 AM, Marius Kjeldahl <marius....@gmail.com> wrote:

I've struggeled with IndexedDB for more than a year. It's completely unusable unless you have a very simple use-case (static really simple schema).

It's definitely unfortunate that up until about 8 months ago, Chrome used the setVersion API from earlier versions of the IDB spec. That made cross-browser development difficult, and also meant that documentation out there was lacking. Have you taken a look since we've updated Chrome to match the latest version of the spec and the behavior in other browsers?

 

Considering bugs are being fixed at glacial speed and even simple test-cases crash by simple bashing the reload button a few times (locking up the database completely), I believe there simply is no client side database like storage solution (localStorage does not cut it either, although that may at least be more stable).

Which bugs have you filed at crbug.com that you feel aren't getting the attention they deserve?

 

I simply gave up trying to write browser based SPA applications; if it runs in the browser, it needs a server, and on phone/tablets you need to use the native solutions (sqlite on Android for instance).

Thanks,

Marius K.

On Monday, 20 May 2013 06:35:51 UTC+2, Aaron Shafovaloff wrote:

OK, I'm back. This seems to be more fickle than I reported. Not hard to reproduce, but hard to find a concrete cause.

As noted in the bug, this appears to be working as intended - the first connection to the database is not explicitly closed, and is therefore held open until the first request is reclaimed by garbage collection, preventing the version change from proceeding. 

It's entirely possible that there's a bug lurking in there, so please do provide more information in the bug - http://crbug.com/242115

 

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.

[Marius Kjeldahl]

On Monday, May 20, 2013 9:28:35 PM UTC+2, Joshua Bell wrote:

It's definitely unfortunate that up until about 8 months ago, Chrome used the setVersion API from earlier versions of the IDB spec. That made cross-browser development difficult, and also meant that documentation out there was lacking. Have you taken a look since we've updated Chrome to match the latest version of the spec and the behavior in other browsers?

I last tried it in February, and noticed it had gotten better. I've contributed patches to the Backbone IndexedDB adapter on multiple occasions and after getting the tests to run fine in Chrome again I though everything finally worked. Until I started bashing the reload key where the database would get stuck (locked). The debugging tools also do not seem trustworthy; sometimes it shows stuff that really is not there and do not show stuff that supposedly IS there. Lots of manual refresh things needed (from higher levels).

 

Which bugs have you filed at crbug.com that you feel aren't getting the attention they deserve?

None. But some of the earlier bugs I noticed was for instance missing API support for something as basic as dropping a database, which together with experiences since then have led me to conclude that IndexedDB in Chrome has been half baked for a long time. Things may have finally changed, but by now my clients are running native Android and my web clients still need a backend ;-).

To be honest, the documentation for IndexedDB was never in a stage where I even dreamed of supporting the driver development, which probably make me less qualified to comment of the state of the implementation. But it is very comforting that somebody finally is stepping up and defending it; hopefully it already is or will be usable in the near future.

 

Thanks,

Marius K.

[Vladyslav Volovyk]

IndexedDB was worstest horror in all my 15+ years pro programmer practice.

Was selected it as every single source mark all other solutions for storing the data locally or as deprecated or as not ready to prime time, but regret so to the unbelievable extent.

Absolutely not robust, crazy bugs, constantly changed API. From Chrome v24 to Chrome v26 there was a problem that really many users of this DB have the corrupted DB files because of some IndexedDB bug in v24, but in a way that actually not affect father operations. So actualy data was not affected. corruption was mainly in temporary files, which must be purged anyway. Yet in v26 developers decide to just wipe out such DBses completely and start from scratch!!!!!!!!!!

That was a fluke I was be able accidentally  to know about this in advance!, or this will be an end of my work after 10-20% of my users will come and report 1 star because of the data lost. In result i just implement the additional backup to WebSQL and FileSystem. Yet it worth to note that FileSystem is based on same engine as IndexedDB and for some of my users was also corrupted and then deleted.

Many of this is in the past (yet cost me literally weeks of work and weird support requests and negative reviews). But worth to note that IndexedDB still have serious problems, for examples in the out of space scenarios it often become corrupted and cannot restore self to continue operations. Also every day i wait a new surprises from the dev team, even in form of bugs, as this thing continue to be developed, much better idea is just to use good old WebSQL. 

[Vladyslav Volovyk]

And this versionchange event is one big mess, i prefer not to touch it at all and change the version of db scheme the other way.

[Alec Flett]

On Tue, May 21, 2013 at 6:08 AM, Vladyslav Volovyk <omn...@gmail.com> wrote:

Absolutely not robust, crazy bugs, constantly changed API. From Chrome v24 to Chrome v26 there was a problem that really many users of this DB have the corrupted DB files because of some IndexedDB bug in v24, but in a way that actually not affect father operations. So actualy data was not affected. corruption was mainly in temporary files, which must be purged anyway. Yet in v26 developers decide to just wipe out such DBses completely and start from scratch!!!!!!!!!!

Were any of these bugs reported? IndexedDB is under very active development in chrome, and there is a very active community here and on stackoverflow that can help you out. we try to be as responsive as possible in both bug reports and on this mailing list and I'm sorry your experiences have been so negative.

There are some known issues when the disk is full, but otherwise, I don't think we're aware of the issues you describe. Can you be specific about "corruption was mainly in temporary files, which must be purged anyway"? its not clear to me if your users actually lost data or not?

Perhaps this really is all in the past but please do engage with a community if you're having issues.

Alec

 

--

You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-html...@chromium.org.

[Vladyslav Volovyk]

Maybe not worth to continue this rumors, it was mostly my emotional reaction after all the horrors, which is all fixed already i think. 

But will confirm some things, just to not throws a shadow on a current state of the IndexedDB.

On Tue, May 21, 2013 at 6:08 AM, Vladyslav Volovyk <omn...@gmail.com> wrote:

Absolutely not robust, crazy bugs, constantly changed API. From Chrome v24 to Chrome v26 there was a problem that really many users of this DB have the corrupted DB files because of some IndexedDB bug in v24, but in a way that actually not affect father operations. So actualy data was not affected. corruption was mainly in temporary files, which must be purged anyway. Yet in v26 developers decide to just wipe out such DBses completely and start from scratch!!!!!!!!!!

Were any of these bugs reported?

They exist. And as i said, i think all of them is fixed now, or not an issues anymore, for some other reasons...

And basically the fact that i publish them helps me because somebody from the dev team contact me and warn about imminent doomsday which was coming with Chrome v26 release, so i just switch all my user to other technologies, and because of this nobody lost the data.

IndexedDB is under very active development in chrome,

And it is the problem. Yet maybe inevitable, but to declare the WebSQL as deprecated, a year ago, it was prematurely ... I think that IndexedDB is only now, in v26, just start to be robust and stable enough to be used. 

 

and there is a very active community here and on stackoverflow that can help you out. we try to be as responsive as possible in both bug reports and on this mailing list

Must confirm so, it is true.

There are some known issues when the disk is full, but otherwise, I don't think we're aware of the issues you describe. Can you be specific about "corruption was mainly in temporary files, which must be purged anyway"? its not clear to me if your users actually lost data or not?

The bug was in Chrome v24, in v25 it was fixed (so the files structure stopped become corrupted on some rare occasions (yet when you have tens of thousands users... you know, and in some scenarios and usage patterns this was not so rare at all) , yet without deleting the already corrupted databases (which continue to work ok, at least for me and in my case), in v26 all the corrupted databases was deleted.I don't know the number of this issue, and it is a history already, but the fact that the databases was just deleted is slightly shocking if for true (yet maybe this was a right solution, know nothing about the full picture, for me such corrupted databases continued to work ok, they just did not shrink in size and not delete sst files which contains updates of the same key), yet as i already said i manage to switch to other methods of storing the data before the wipe out day, so the IndexedDB databases was recreated, but was successfully filled back from other sources.