Hi Nolan, Thanks a lot for your comments! I would also like to take this chance to thank you for all your awesome projects around couchdb/pouchdb and those helpful articles on http://pouchdb <http://pouchdb/>.com/blog. I’ve learned a lot recently from your work. ;-)
Yes, after more reading about couchdb/pouchdb, I also realized that my original thought of “cache layer” is problematic as what you stated. The pouchdb database is more like a double of its remote counterpart, as long as you live up with “eventual consistency”. The steps you summarized for the workaround you took for npm-browser is educational to me. Thanks again! -Ying > On Oct 9, 2015, at 11:27, Nolan Lawson <[email protected]> wrote: > > Hi Ying, > > Using PouchDB as a "cache layer" might be a misleading way of thinking > about it. Typically PouchDB is used to copy all data from a remote CouchDB > to the local database; if you don't want to copy everything, then people > usually use filtered replication or break up the server database into many > smaller ones (e.g. one database per user). > > In fact, even determining that the local one is "out of date" with the > remote one is somewhat difficult (although you can do it; see how the > PouchDB checkpointer works for some examples). So querying against the > local first, then checking if it "fails" might not make much sense, because > there's no real way to know that it "failed" (other than to immediately go > to the remote as well and ask for the same results, in which case you lose > all the performance/offline benefits of using the local store in the first > place). > > I ran into a similar problem with http://npm-browser.com, and I worked > around it using the following technique: > > 1) Start the sync > 2) Wait for the local number of docs to match the remote number of docs > 3) In the meantime, run remote queries > 4) Once the local number of docs matches the remote number, switch to > purely local queries > 5) Continue syncing, as changes from the remote arrive over time > > The benefit of this approach is that local is always faster than remote, so > the interface speeds up quite a bit once the initial sync is complete. The > downside is that queries can be slightly out of date. But "eventual > consistency" is part of the model of CouchDB/PouchDB (since it's an AP > database in the CAP theorem), so this is to be expected. > > Hope that helps! If you run into any issues with pouchdb-find, feel free to > file them on Github. :) > > Cheers, > Nolan > > > On Thu, Oct 1, 2015 at 6:44 PM, Ying Bian <[email protected]> wrote: > >> Joel, >> >> Not a big deal as I’m not a native English speaker either. ;-) I >> appreciate your help. >> Yes, my service would be cloudant like, but it would be tailored for my >> specialized use cases. >> >> As for “couchdb & pouchdb transparent”, what I wanted to achieve: >> >> Whenever a query is triggered, it queries against local pouchdb first, and >> would only switch to >> remote couchdb if it fails. i.e: the local pouchdb acts more like a >> “cache” layer. Is this possible >> to do just with the current interface? Or do I need a thin wrapper for >> this logic? >> >> -Ying >> >>> On Oct 2, 2015, at 04:16, Joel Wallis <[email protected]> wrote: >>> >>> @Dale and @Ying, I'm sorry if my text sounds aggressive, that was really >>> not what I meant. English is just my second language so I really don't >> even >>> have an idea of how bad "pretending to develop" sounds at the given >>> context. I was just trying to help. >>> >>> Please ignore my message above. >>> >>> 2015-10-01 15:55 GMT-03:00 Dale Harvey <[email protected]>: >>> >>>> Ying >>>> >>>> CouchDB 2.0 has long been in development and is nearing a beta release, >> I >>>> wouldnt be switching existing services to it, but for new product >>>> development, particularly one that needs mango then I would probably >>>> recommend doing so. Mango is already supported in CouchDB 2.0, >> pouchdb-find >>>> will transparently switch to using it if you are speaking to CouchDB 2.0 >>>> >>>> And Joel, this isnt really a suitable mailing list for questioning >> peoples >>>> 'product differentials' particularly in that aggressive way "pretending >> to >>>> develop" >>>> >>>> Cheers >>>> Dale >>>> >>>> >>>> On 1 October 2015 at 17:32, Joel Wallis <[email protected]> wrote: >>>> >>>>> You are actually describing Cloudant as the service you are pretending >> to >>>>> develop. Do you have any planned diferential for this? (Just asking, as >>>>> product manager, to help you plan your product.) >>>>> >>>>> And, PouchDB can be used as an interface for a completely remote >> CouchDB >>>>> database. Is that what you mean with "couch & pouch transparent"? If >> not, >>>>> what are the key diferentials for your implementation? (Just asking, >> as a >>>>> software developer, to help you plan your implementation.) >>>>> >>>>> 2015-10-01 10:34 GMT-03:00 Ying Bian <[email protected]>: >>>>> >>>>>> Dear couchdb developers and users, >>>>>> >>>>>> I’m new to couchdb & pouchdb and I’m looking forward to some comments >>>> to >>>>>> the following problem: >>>>>> >>>>>> I want to setup a couchdb service in the cloud and provide an SDK to >> my >>>>>> users for them to use in their apps. They can also use pouchdb as a >>>> local >>>>>> replication of their data. An important part of the SDK is the query >>>>>> interface. I want it to be developer-friendly as much as possible. The >>>>>> map/reduce API is too complex for developers with no similar >>>> experience. >>>>>> After some investigation, I think maybe [pouchdb-find]( >>>>>> https://github.com/nolanlawson/pouchdb-find < >>>>>> https://github.com/nolanlawson/pouchdb-find>) is worth to try. Its >>>>>> mongodb like query language is more intuitive in my mind. >>>>>> >>>>>> My questions are: >>>>>> >>>>>> 1. Pouchdb-find is still in beta and its documents says "This API is >>>>>> modeled after the Cloudant query API < >>>>>> https://docs.cloudant.com/api/cloudant-query.html>, soon to be merged >>>>>> into CouchDB 2.0.” Is the support already merged into couchdb 2.0? >>>>> What’s >>>>>> the delivery plan for couchdb 2.0? Is it to safe to switch to 2.0 now? >>>>>> >>>>>> 2. I want the query interface to be “couch & pouch” transparent: the >>>> same >>>>>> query API would be used for both local pouchdb and remote couchdb. I >>>>>> suppose this is not a problem. Am I right? >>>>>> >>>>>> Any comments would be much appreciated. >>>>>> >>>>>> -Ying >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Joel Wallis Jucá >>>>> joelwallis.com >>>>> >>>> >>> >>> >>> >>> -- >>> Joel Wallis Jucá >>> joelwallis.com >> >> > > > -- > Nolan Lawson > nolanlawson.com > github.com/nolanlawson
