search

pouchdb / express-pouchdb

⚠️⚠️⚠️ THIS REPO HAS MOVED ⚠️⚠️⚠️
143 stars 52 forks source link

consider removing temp views from minimumForPouchDB mode #191

Closed willholley closed 9 years ago

willholley commented 9 years ago

Suggested by @marten-de-vries in https://github.com/pouchdb/pouchdb/pull/3391. Temp views are not supported in CouchDB 2.0 or Cloudant.

nolanlawson commented 9 years ago

Sort of off-topic, but I think this is a good time to have this discussion:

What is the point of PouchDB Server - to emulate CouchDB 1.x or CouchDB 2.x? For the time being it is single-core because PouchDB is single-core, but you could imagine migrating it to a multi-core design.

Personally I would prefer keeping it more consistent with CouchDB 1.x than CouchDB 2.x, just for simplicity's sake and also because there is value in continuing to carry 1.x's baton of a single-core server. Some people might prefer that design.

For temp views, though, I'm happy to drop them as long as it doesn't break Fauxton.

marten-de-vries commented 9 years ago

@nolanlawson Fauxton is broken in minimumForPouchDB/pouchdb-express-router for all but the most basic functions. temp views would just be one to add to the list: replication (/_changes is included, /_replicate isn't), /_security documents, authentication...

As for which API to support: Implementing clustering is not my priority either. I can imagine some of CouchDB 2.0's other features ending up in express-pouchdb though. Things like the new query api (mango, maybe based on the plug-in you started?), validate_doc_read which is sometime going to land upstream, that kind of thing. So I'm pretty much proposing a hybrid, the result would, with the exception of a few clustering query parameters and maybe some legacy functions (which we could deprecate too if it makes sense), probably be pretty close to CouchDB 2.0's user facing API.

nolanlawson commented 9 years ago

Sounds good to me. Temp views are something I'm happy to throw under the bus for minimumForPouchDB; in general, though, I think they're kind of useful for testing in Fauxton, although definitely a footgun.

willholley commented 9 years ago

Just to clarify, besides the temp view deprecation there shouldn't be any significant changes to the single node API in CouchDB 2.X. CouchDB 2.X can be used as a single node or a cluster - the single node setup is just a subset of the functionality.

marten-de-vries commented 9 years ago

Just checked: Fauxton doesn't use temp views (anymore?). It just calls /_all_docs & runs the map/reduce function in memory when you click 'Preview'.

My preference for now would be to keep temp views in for backwards compatibility (including that mapreduce expects http dbs to implement it), but to kick them out if they ever become a problem somehow (or we decide it's time to follow CouchDB 2.0's example).

Apart from that the single node CouchDB api seems to be the thing to aim for. Convenient extra is that couchdb-harness, which is based on couchdb's master branch, probably targets that too. :)

nolanlawson commented 9 years ago

@willholley: there's also the "seqs as integers" thing, which PouchDB Server will probably continue to do, since that's what PouchDB does.

I agree with @marten-de-vries; keep temp views for backwards compat. As for the new Mango queries - workin' on it! :)

marten-de-vries commented 9 years ago

Seems like there is consensus: keep temp views in minimumForPouchDB for now.