You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a few projects where we make use of PouchDB’s different adapters (level and http in our case) to run software in different environments. We also use couchdb-bootstrap, which doesn’t work with PouchDB instances itself, but only a CouchDB server.
In theory, would this project (and the sub-projects it is built from) accept a set of PRs that add support for PouchDB instances instead of just URLs that are passed to nano?
A first implementation could do if/else switches at the various places where they are needed, but one could argue that once you use PouchDB and since it can use a CouchDB URL using the http adapter, wouldn’t it make sense to just stop using nano here. This question doesn’t ask to do the full replacement, just additional support for bootstrapping a PouchDB instance, but a wholesale transition might be less effort.
I like the idea of supporting a PouchDB adapter and would happily accept a pull request for this. Also, I agree that using PouchDB instead of Nano here would make absolutely sense. We would need to carefully communicate such breaking change here, though.
Another thing is that I wanted to transition to a mono repo approach since long time - if you're at it and if it would make things for you easier, I'd also accept a pull for this ;)
We have a few projects where we make use of PouchDB’s different adapters (level and http in our case) to run software in different environments. We also use couchdb-bootstrap, which doesn’t work with PouchDB instances itself, but only a CouchDB server.
In theory, would this project (and the sub-projects it is built from) accept a set of PRs that add support for PouchDB instances instead of just URLs that are passed to nano?
A first implementation could do if/else switches at the various places where they are needed, but one could argue that once you use PouchDB and since it can use a CouchDB URL using the http adapter, wouldn’t it make sense to just stop using nano here. This question doesn’t ask to do the full replacement, just additional support for bootstrapping a PouchDB instance, but a wholesale transition might be less effort.
It’d be totally fine to say “no, out of scope” :)
@jo
The text was updated successfully, but these errors were encountered: