I've been learning CouchDB and PouchDB simultaneously, and perhaps that's why I'm having trouble understanding the way PouchDB handles CouchDB Views.
I've successfully created a View in CouchDB, and querying it over HTTP (the CouchDB way) is successful.
What I'm having trouble with is how to query the view using PouchDB, a front-end abstraction and part-time(?) caching library for CouchDB or CouchDB-like databases.
According to this blog post PouchDB introduced something called 'persistent map/reduce' in version 2.2.0. But as I've already got comfortable using Views in CouchDB, I'm confused as to what problem PouchDB is trying to solve.
Are persistent map/reduces in PouchDB merely a way of persisting Views to CouchDB from the comfort of the front end? And if so, why is there no obvious way of utilising Views that have already been written in the back? And also, how is it that PouchDB could not do this from inception - I understand Views to be the backbone of CouchDB's ability to index.
Let's say I decide that there is a View (or Index in SQL-land) that I know I will be using often. Should I really be creating that via the front end using PouchDB? Does this not mean I'll run into problems as to when I create the View and whether I should overwrite them? Is PocuhDB simply using the CouchDB Views behind the scenes, or are they creating their own map/reduce queries in the Front-end, thereby loosing the efficiency of having the Views updated by the backend when things are re-indexed.
In essence I guess my question is: is PouchDB re-inventing the wheel at the cost of efficiency, or simply taking ownership of CouchDB's Indexing functionality? Or something else all together?
I kept my original answer at the bottom, but downvotes suggest it wasn't clear, so let me address the questions directly:
The answer to this depends on what is meant by "the view". First consider "the view" meaning a CouchDB view. A CouchDB instance, can have views, which can be queried by the PouchDB library. This is done by instantiating PouchDB and pointing it at the CouchDB instance:
If the couchDB instance has a view called "documents_by_date", then you can query it with your pouchdb instance:
PouchDB will use the couchdb HTTP interface to query the documents_by_date view. All of the heavy work of searching through the documents and caching the results is handled by couchdb on the couchdb instance. In this example, PouchDB is just sending HTTP requests and returning JSON results.
Now consider the other meaning of the "the view". PouchDB can also act as a database running entirely independently in the browser. All of the data gets stored in the browser. You can also use views to index this data, just like with CouchDB. Initially PouchDB didn't have the capability to cache, so a PouchDB view simply meant iterating over every document in the database to create the index every time the query was called. Eventually caching was added, which meant persistent views, which means that every document doesn't have to be iterated over when a query is done. So how do you query a PouchDB view?
This is exactly the same as before, except the PouchDB instance no longer points at a remote CouchDB database (http://example...) but is now pointing at a local PouchDB database (sample_database). All of the querying and indexing and processing is all just happening in the browser.
No. Persistent map/reduces in PouchDB allow you to query data stored locally in PouchDB. They have nothing to do with CouchDB other than using the same syntax.
It's not so (as explained above), however it is possible to use views written for CouchDB as views for PouchDB. The syntax (a function on a document that emits) is the same. On CouchDB and PouchDB a view is a design document ("_design/documents_by_date") with a views property that holds the view logic. As long as that design document is in your database (PouchDB or CouchDB) you can query it.
PouchDB has always been able to use views to query a CouchDB database. However, initially, as you point out, PouchDB wasn't able to index queries to PouchDB databases. I expect that the main reason is the typical PouchDB use case. Since PouchDB databases run in a browser, they are never going to be massive databases like what CouchDB is designed for. Rather, a typical use case might be for a PouchDB database to mirror ("replicate") a subset of a CouchDB database. With a small database the benefits of caching are negligible, so this feature was not prioritized.
The problem here is that you are asking about view creation. The view is simply a design document that needs to be saved in a couchdb or pouchdb database. How you create it isn't important (kind of like which editor should be used to write SQL queries). Whether you want that view to run against remote (couchdb) data or local (pouchdb) data will determine where you end up saving that view.
Not sure what you mean by overwrite them.
Again, this comes down to understanding that you can query couchdb databases or pouchdb databases with pouchdb. The efficiency question comes down to the use case, and thinking about it in terms of front-end vs back-end doesn't map very well to many PouchDB use cases.
Neither of these options (re-inventing the wheel or taking ownership) are correct. PouchDB is at least two things: a client for CouchDB and a standalong CouchDB implementation in javascript that runs in the browser. It enables an entirely new class of web applications, including the ability for a web site to work offline with full database capability.
Original Answer below:
PouchDB is (at least) two things:
An implementation of CouchDB in javascript, meaning that you get a fully functional database that works just like CouchDB except the entire thing runs locally in the browser (even when you are offline). Because of PouchDB's ability to replicate with CouchDB it can act as a local (browser-based) cache for a CouchDB. It can also act as a standalone dtabase.
PouchDB is also a javascript library that lets you access remote (cloud based) instances of CouchDB .
When you create an instance of PouchDB you tell it to either connect to a remote CouchDB instance or to create a local instance (in the browser).
When you perform a query you either run that query on the remote instance or the local instance, depending on which of the above you have instantiated. If it is a remote DB, then the query looks through all of the data on the remote database. If it is a local DB, then the query looks through all of the data in the local database. Local queries can make use of indexes in exactly the same was as couchdb does on the server - these are called persistent queries - or you can do a temporary query which looks through every document in your database. Whether you are querying a remote couchdb or a local pouchdb and whether you are using persistent queries or temporary ones, depends on a lot of factors like, whether your application needs to work offline, how much data you have, whether you are replicating the entire database to your local instance, etc.
PouchDB has not just re-invented the wheel. It has taken all of the advantages of CouchDB and made them work in the browser even when there is no internet connection.