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
