Skip to content

Releases: pouchdb-community/ember-pouch

If you don't index it, it doesn't exist

05 Dec 13:02
0b7ebc6
Compare
Choose a tag to compare
Pre-release
  • Set PouchDb indexeddb adapter as default instead of idb adapter to use native views.
  • Generate adapters/application.js at installation.
  • move package.json dependencies to the default blueprint.
  • removed Adapter fixDeleteBug flag. We now do a client side destroyRecord with custom adapterOptions to signal to the ember-data store that the record is deleted. So no more hacking ember-data is needed in the addon to support the server pushed deletes.

Patience is not an absence of action; rather it is "timing"

06 Jun 09:38
fd7ea36
Compare
Choose a tag to compare
  • Updated to support latest Ember 4.x (fixed isDeleted issues)
  • Switch to PouchDB 7.3.0. Getting ready to use the indexeddb-adapter
  • Embroider safe and compatible scenarios supported. Ember Pouch works fine with Ember 4.x projects.
  • Update application adapter example to use class property #262
  • Fix Adapter Blueprint for Ember Octane #257

How did it get so late so soon?

02 Apr 11:15
Compare
Choose a tag to compare
  • Use ember-auto-import and pouchdb-browser to ease the installation process
  • relational-pouch@4.0.0
  • Use Octane Blueprints

It must be lived forwards

12 Jul 11:12
Compare
Choose a tag to compare
  • Switch to PouchDB 7.0.0

Crazy enough to change the world

28 Jun 10:53
Compare
Choose a tag to compare
  • Don't unloadRecord a deleted document in onChange, only mark as deleted. This fixes some bugs with hasMany arrays corrupting in newer ember-data versions. Not unloading records also seems safer for routes that have that model active.

Ho’oponopono helps us

26 Jun 14:05
fa95a63
Compare
Choose a tag to compare
  • Adapter fixDeleteBug flag. Defaults to true. Fixes emberjs/data#4963 and related issues that don't seem to work well with server side delete notifications.
  • Track newly inserted records, so unloadedDocumentChanged is not called for those. Otherwise a race-condition can occur where onChange is faster than the save. This can result in the document being inserted in the store via unloadedDocumentChanged before the save returns to ember-data. This will result in an assert that the id is already present in the store.

Nothing renews like forget

26 Jan 21:35
Compare
Choose a tag to compare

Important [breaking] changes in this release:

  • Don't save hasMany child ids is on by default.
  • Eventually Consistent is on by default.
  • dontsavehasmany and dontsave flags should be removed.
  • In some hasMany cases you need to specify the new option save: true on the model.

Don't save hasMany child ids

To be more in line with the normal ember data way of saving hasMany - belongsTo relationships, ember-pouch now has an option to not save the child ids on the hasMany side. This prevents the extra need to save the hasMany side. For a more detailed explanation please read the relational-pouch documentation

This new mode can be disabled for a hasMany relationship by specifying the option save: true on the relationship. An application wide setting named ENV.emberPouch.saveHasMany can also be set to true to make all hasMany relationships behave the old way.

Using this mode does impose a slight runtime overhead, since this will use db.find and database indexes to search for the child ids. The indexes are created automatically for you. But large changes to the model might require you to clean up old, unused indexes.

!Important
This mode is the default from version 5 on wards. Before that it was called dontsave and dontsavehasmany

Eventually Consistent

Following the CouchDB consistency model, we have introduced ENV.emberPouch.eventuallyConsistent. This feature is on by default. So if you want the old behavior you'll have to disable this flag.

findRecord now returns a long running Promise if the record is not found. It only rejects the promise if a deletion of the record is found. Otherwise this promise will wait for eternity to resolve.
This makes sure that belongsTo relations that have been loaded in an unexpected order will still resolve correctly. This makes sure that ember-data does not set the belongsTo to null if the Pouch replicate would have loaded the related object later on. (This only works for async belongsTo, sync versions will need this to be implemented in relational-pouch)

Anybody can serve

18 Jan 11:29
Compare
Choose a tag to compare
Anybody can serve Pre-release
Pre-release
  • Add register-version.js to vendor/ember-pouch #210
  • Update documentation about Offline First #209

Find your place on the planet

12 Jan 15:15
Compare
Choose a tag to compare
Pre-release

Always a plural when mad

08 Jan 12:29
Compare
Choose a tag to compare
Pre-release
  • Resolve Ember.String.pluralize() deprecation