This version is not covered by your current version range.
Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.
I recommend you look into these changes and try to get onto the latest version of hoodie.
Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.
Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right?
Are you unsure about how things are supposed to work?
There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.
Before, change events (incl. add, update, remove) have only been triggered when using the custom APIs like .add() or .update(). Now they get always triggered, including for changes replicated into the database. hoodiehq/pouchdb-hoodie-api@1958c42
the order of when the methods’ promises resolve and the events get triggered cannot be guaranteed as we rely on PouchDB’s .changes(). We would love to enforce promises to resolve after changes get emitted, but the required complexity to do that is not worth it.
separate methods like require(pouchdb-hoodie-api/add) can no longer be required directly
The reason for that is that all the methods now also accept a prefix argument which by default is null. That way we don’t need to implement each method twice, once for store.add, and once for store.withIdPrefix(test/).add
We no longer map PouchDB’s ._id property to .id, instead we pass trough docs from PouchDB 1:1. Also the timestamps are now all namespaced with .hoodie (doc.createdAt becomes doc.hoodie.createdAt)
For hoodie.account:
account.ready has been removed. All APIs are now asynchronous, no setup is needed any longer
account.fetch() and account.profile.fetch() have been removed. Use account.get() and acc*account.fetch()andaccount.profile.fetch()have been removed. Useaccount.get()andacc* account.fetch() and account.profile.fetch() have been removed. Use account.get() and acc*account.fetch()andaccount.profile.fetch()have been removedrequest *account.fetch()andaccount.profile.fetch()have been removed. Useaccount.following conditions is true
User is signed out
Only id and or session properties are requested
options.local is set to true
account.hasInvalidSession() has been removed. Use account.get(session) instead (check of session.invalid)
account.isSignedIn() has been removed. Use account.get(session) instead.
(9d636fa8)
*
The store instance which server.plugins.store.api.open(dbName) resolves to
has several breaking changes via pouchdb-hoodie-api@2.0.0
Before, change events (incl. add, update, remove) have only been triggered
when using the custom APIs like .add() or .update(). Now they get always
triggered, including for changes replicated into the database.
the order of when the methods’ promises resolve and the events get triggered
cannot be guaranteed as we rely on PouchDB’s .changes(). We would love to
enforce promises to resolve after changes get emitted, but the required
complexity to do that is not worth it.
We no longer map PouchDB’s ._id property to .id, instead we pass trough docs
from PouchDB 1:1. Also the timestamps are now all namespaced with .hoodie (doc.createdAt becomes doc.hoodie.createdAt)
Unless you use the server.plugins.store.api.open(name) API you are not affected by any of this.
With Integrationsfirst-class bot support landed on GitHub and we’ve rewritten Greenkeeper to take full advantage of it. Simpler setup, fewer pull-requests, faster than ever.
Screencast Try it today. Free for private repositories during beta.
Hello lovely humans,
hoodie just published its new version 28.0.0.
This version is not covered by your current version range.
Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.
I recommend you look into these changes and try to get onto the latest version of hoodie. Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.
Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right? Are you unsure about how things are supposed to work?
There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.
Good luck with your project :sparkles:
You rock!
:palm_tree:
GitHub Release
<a name"28.0.0">
28.0.0 (2017-03-09)
Breaking Changes
For
hoodie.store:Before, change events (incl. add, update, remove) have only been triggered when using the custom APIs like
.add()or.update(). Now they get always triggered, including for changes replicated into the database. hoodiehq/pouchdb-hoodie-api@1958c42the order of when the methods’ promises resolve and the events get triggered cannot be guaranteed as we rely on PouchDB’s .changes(). We would love to enforce promises to resolve after changes get emitted, but the required complexity to do that is not worth it.
separate methods like
require(pouchdb-hoodie-api/add)can no longer be required directlyThe reason for that is that all the methods now also accept a
prefixargument which by default is null. That way we don’t need to implement each method twice, once forstore.add, and once forstore.withIdPrefix(test/).addWe no longer map PouchDB’s
._idproperty to.id, instead we pass trough docs from PouchDB 1:1. Also the timestamps are now all namespaced with.hoodie(doc.createdAtbecomesdoc.hoodie.createdAt)For
hoodie.account:account.readyhas been removed. All APIs are now asynchronous, no setup is needed any longeraccount.fetch()andaccount.profile.fetch()have been removed. Useaccount.get()andacc*account.fetch()andaccount.profile.fetch()have been removed. Useaccount.get()andacc*account.fetch()andaccount.profile.fetch()have been removed. Useaccount.get()andacc*account.fetch()andaccount.profile.fetch()have been removedrequest *account.fetch()andaccount.profile.fetch()have been removed. Useaccount.following conditions is trueidand orsessionproperties are requestedoptions.localis set to trueaccount.hasInvalidSession()has been removed. Useaccount.get(session)instead (check ofsession.invalid)account.isSignedIn()has been removed. Useaccount.get(session)instead.(9d636fa8)
*
The store instance which
server.plugins.store.api.open(dbName)resolves tohas several breaking changes via pouchdb-hoodie-api@2.0.0
Before, change events (incl. add, update, remove) have only been triggered
when using the custom APIs like
.add()or.update(). Now they get alwaystriggered, including for changes replicated into the database.
the order of when the methods’ promises resolve and the events get triggered
cannot be guaranteed as we rely on PouchDB’s
.changes(). We would love toenforce promises to resolve after changes get emitted, but the required
complexity to do that is not worth it.
We no longer map PouchDB’s ._id property to .id, instead we pass trough docs
from PouchDB 1:1. Also the timestamps are now all namespaced with
.hoodie(doc.createdAtbecomesdoc.hoodie.createdAt)Unless you use the
server.plugins.store.api.open(name)API you are not affected by any of this.(ba5301f2)
Screencast
Try it today. Free for private repositories during beta.