Storage version gets increased but not all indexes are created

[tp]

For example, this is part of my storage definition:

db.version(20)
      .stores({
cityIndex: 'id,displayName,*displayNameParts,isDeleted,countryRef,[countryRef+isDeleted],autoCreated,needsReview,[autoCreated+isDeleted],[needsReview+isDeleted],[autoCreated+needsReview+isDeleted],[autoCreated+countryRef+needsReview+isDeleted],[autoCreated+countryRef+needsReview+isDeleted],[autoCreated+robotsNoIndex+isDeleted],[autoCreated+needsReview+robotsNoIndex+isDeleted],[autoCreated+countryRef+robotsNoIndex+isDeleted],[autoCreated+countryRef+needsReview+robotsNoIndex+isDeleted]',
});

Those are by my count 17 indexes.

But not all of them get created, even though the version gets incremented in the browser.

Firefox: 13 / 17 indexes:

Chrome: 15 / 17 indexes:

Any ideas?

[dfahlander]

Thanks for finding. I'll try to reproduce it in a unit test later on today.

[tp]

@dfahlander Thanks. While this should definitely not fail silently, I now question my approach using all the compound indexes. I have read the article, that .or is quite performant, since it only operates on the primary keys.

Is and equally performant? Would you advise to switch from compound indexes to and for the highly variable queries?

[dfahlander]

Nope. Compound indexes are the best pick for 'and' operations. The and() method is just a javascript filter.

[dfahlander]

Found one possible issue: "[autoCreated+countryRef+needsReview+isDeleted]" is entered twice.

Still examining why it fails silently...

[dfahlander]

Actually it is not failing silently if you've catched the db.open() call, or a subsequent call to use the database. It failed actually to open.

It's still an issue that the half-created database is still there and that the upgrade transaction is not aborted correctly, which I now trigger in a unit test and will resolve (not committed yet).

For your application though, just remove your duplicate index name "[autoCreated+countryRef+needsReview+isDeleted]". You might need to delete the database and recreate it because it was left in that half-upgraded state due to this issue.

[tp]

Strange, I actually look for errors on db.open:

db.open()
  .then(() => {
    console.log('opened the database');
  })
  .catch(function(error) {
    alert('Uh oh : ' + error);
  });

Since this is just a a development setup for now deleting the DB is no problem.

For future reference: Is inserting an empty intermediate version like this db.version(23).stores({}); enough?

[dfahlander]

It's not strange when I think about it. In my tests I always recreate the
db and get the error. The error only happens the first time. Once it has
happened, it will succeed on next open without complaining...
Den 20 maj 2015 18:09 skrev "Timm Preetz" [email protected]:

Strange, I actually look for errors on db.open:

db.open()
.then(() => {
console.log('opened the database');
})
.catch(function(error) {
alert('Uh oh : ' + error);
});

Since this is just a a development setup for now deleting the DB is no
problem.

For future reference: Is inserting an empty intermediate version like this
db.version(23).stores({}); enough?

—
Reply to this email directly or view it on GitHub
#100 (comment)
.

[dfahlander]

I fixed the issue by always aborting the upgrade-transaction if any error occur. However, after running the unit test suite there has been some problems with other unit tests that I need to investigate.