(Chrome) The requested version (1) is less than the existing version (2)

[ioleo]

I keep getting this error:

Uncaught (in promise) DOMError {}message: "The requested version (1) is less than the existing version (2)."name: "VersionError"__proto__: DOMError

I am useing ember + ember data v2.2. Is there any way to fix this?

I keep getting it when I try to transition to route with model() { return this.store.findAll('scene'); } where scene is a simple DS.Model with 3 string fields...

[ioleo]

This happens on Chrome. It works on firefox. I read that this addon fallsback to local storage... but it seems it does not?

[frederikbosch]

What version this adapter are you using? If it is the latest (2.2.0), and you have the opportunity to rollback to 2.1.0, please do. In this latest release I upgraded the localforage dependency to 1.3.x. That might be the issue.

[ioleo]

• I've installed Ember CLI via npm install -g ember-cli.
• Then created a project via ember new my-app.
• Then edited packages.json and bower.json to update ember and ember-data to ~2.0.
• Then bower install and npm install.
• Finally I followed this projects README and did ember install ember-localforage-adapter.

My packages.json devDependencies:

{
    "broccoli-asset-rev": "^2.1.2",
    "ember-cli": "1.13.8",
    "ember-cli-app-version": "0.5.0",
    "ember-cli-babel": "^5.1.3",
    "ember-cli-bootstrap-sassy": "0.5.1",
    "ember-cli-content-security-policy": "0.4.0",
    "ember-cli-dependency-checker": "^1.0.1",
    "ember-cli-font-awesome": "1.3.0",
    "ember-cli-htmlbars": "0.7.9",
    "ember-cli-htmlbars-inline-precompile": "^0.2.0",
    "ember-cli-ic-ajax": "0.2.1",
    "ember-cli-inject-live-reload": "^1.3.1",
    "ember-cli-qunit": "^1.0.0",
    "ember-cli-release": "0.2.3",
    "ember-cli-sass": "5.2.1",
    "ember-cli-sri": "^1.0.3",
    "ember-cli-uglify": "^1.2.0",
    "ember-data": "~2.0",
    "ember-disable-proxy-controllers": "^1.0.0",
    "ember-export-application-global": "^1.0.3",
    "ember-localforage-adapter": "2.2.0"
  }

My bower.json dependencies:

{
    "ember": "~2.0",
    "ember-cli-shims": "~0.0.3",
    "ember-cli-test-loader": "~0.1.3",
    "ember-data": "~2.0",
    "ember-load-initializers": "~0.1.5",
    "ember-qunit": "~0.4",
    "ember-qunit-notifications": "~0.0.7",
    "ember-resolver": "~0.1",
    "jquery": "~1.11",
    "loader.js": "~3.2",
    "qunit": "~1.18",
    "bootstrap": "~3.3",
    "font-awesome": "~4.4.0",
    "moment": "~2.8",
    "moment-timezone": "~0.1",
    "bootstrap-sass": "~3.3.6",
    "blob-polyfill": "~1.0.20150320",
    "localforage": "~1.2.1"
  }

The component.json of bower_components\localforage contains version": "1.2.10"

[frederikbosch]

@loostro Hmm, I see what happens, in our most recent version I forgot to upgrade the blueprint. I just did that in this commit. Can you change your bower.json to "localforage": "~1.3.1" and update? Is the bug still there then?

In my previous message I pasted the wrong link. It looks like a localforage bug. I will try to replicate it on my machine. Which Chrome version are you using?

[sebweaver]

First of all, check the version of localforage is 1.3.1 (not 1.3.0 which is buggy with Ember). If not, replace the following:

"localforage": "~1.2.1"

By:

"localforage": "~1.3.1"

Then, check the way you created localforage instance and don't specify any version (indexedDB driver will manage it by itself).

[ioleo]

• I updated the dependency to "localforage": "~1.3.1" and bower install which installed localforage#1.3.1
• Run again ember server

And it works! Thank you very much :)

I am useing latest Chrome 47.0.2526.106 m on Windows 8.

[frederikbosch]

Great. I will release a new version of the adapter today, with the latest commit included.

[frederikbosch]

@sebweaver Shall I cherry pick this commit for version 2.2.1 or do you want to include your recent commits also?

[sebweaver]

Include my recent commits too, they improve several things.

[sebweaver]

BTW, since we removed all needless copies (your commits and mine) I've noticed a significative impact on performance of my application, haven't you?

If I had time I would create a benchmark to measure it and know in which proportion. :smiley:

[frederikbosch]

@sebweaver Honoustly, my app with this adapter works perfectly in production. I have no reason to implement changes at this moment.

For a new app, I am thinking of creating a ember-connectivity-adapter, and try to do things different then all those sync related apps. I have some ideas for this. Now I have to find some time to implement them.

By the way, that idea remembers me of the fact that we should consider update generateIdForRecord to a real guid/uuid implementation. The current implementation is randomness for beginners. I think we'd better rely on an existing package for this, rather then create something ourselves. Do you know if Ember has this built-in? Or should we add a new external dependency for this?

[frederikbosch]

For the latter I opened a new issue #56. I also released version 2.2.1.

[sebweaver]

Honoustly, my app with this adapter works perfectly in production. I have no reason to implement changes at this moment.

Of course, but you may test these changes on dev env. What's the size of your database ? May be these changes are not so significative on small databases.

By the way, that idea remembers me of the fact that we should consider update generateIdForRecord to a real guid/uuid implementation. The current implementation is randomness for beginners. I think we'd better rely on an existing package for this, rather then create something ourselves. Do you know if Ember has this built-in? Or should we add a new external dependency for this?

Good idea, because the current mechanism is not very reliable on big database. I already experienced some collisions occasionally.

Do you know if Ember has this built-in? Or should we add a new external dependency for this?

I don't think it's built-in, it's the responsibility of adapters to handle that and both REST and JSONAPI adapters don't implement it. But I'll check to be sure.

[frederikbosch]

My database is huge. You are right, I could do some benchmarking on development environment. What I discovered with my database is that relationships are very expensive in Ember Data. But that was before Ember / Ember Data / ELA 2.0.0. So my production app with ELA is still on 1.13.x. And since it is a mobile private (unpublished) app on a few devices, I will only update when there is a real need.

And when I do, first thing I will check is what all those changes you have made regarding relationships will do with performance. But I think I know the answer to that question!

[sebweaver]

Ouch, indeed, I think the gap performance gap between the version 1.13.x and 2.2.x is huge. Not only in general but specially for your database too, regarding both speed and memory consumption.

I look forward to seeing the result of your own test or benchmark! :smiley:

[ioleo]

@frederikbosch why not simply assign increasing integer numbers as ids?

[frederikbosch]

@loostro That won't work if there are multiple devices or a server that can also generated a sequential ID. If every device has its own database, then it is fine, otherwise: trouble!

[ioleo]

I can recommend hashids. It maps integers to unique strings.