You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2018/10/03 10:42:30 UTC

[GitHub] garrensmith opened a new issue #126: [RFC] Implement Partitions api

garrensmith opened a new issue #126: [RFC] Implement Partitions api 
URL: https://github.com/apache/couchdb-nano/issues/126
 
 
   We are currently adding partition support to CouchDB https://github.com/apache/couchdb/pull/1605
   This document details how I think the api for partitions should work for nano.
   
   Partitions allow a user to store related documents into a `partition` within CouchDB. Using the new partition endpoints this would then allow a user to query only documents in a specific partition. This leads to much faster query time as CouchDB only needs to fetch the documents from a subset of the shards for a db.
   
   To store a document in a partition a user prefixes an id with the partition name e.g `{_id: "partition1:my-doc", "field": "one"}` and `{_id: "partition2:my-doc", "field": "one"}`.
   
   Then using a tradional view to query the document you would use these endpoints:
   Map/Reduce:
   `/my-db/_partition/partition1/_design/my-view`
   
   And for Mango:
   `/my-db/_partition/partition1/_find`
   
   The idea around partitions, which I've hopefully conveyed really quickly above, is that data in a partition is quite separate and when a database is partitioned a user would work with each partition separately. I would like to reflect that kind of thinking in the api. So I propose that we would add a new function called `partition` which accepts a partition name and returns an object for you to query a specific partition. Hopefully the below example explains it.
   
   ```js
   await nano.db.create('db1', {partition: true});
   const db = nano.use('db1');
   await db.insert({
         views: {
           aview: {
             map: "function(doc) {\n  if (doc.group) {\n    emit([doc.some, doc.group], 1);\n }\n}",
             reduce: "_count"
           }
         }
       }
   }, _design/example-query);
   
   
   db.insert({some: "field"}, 'partition1:doc1');
   db.insert({some: "field2"}, 'partition1:doc2');
   db.
   // This goes in partition 2
   db.insert({some: "field2"}, 'partition2:doc1');
   
   const partition1 = db.partition('partition1');
   
   // This will only return doc with id `partition1:doc1`
   const docs = await partition1.find({
      selector: {
        some: "field"
      }
   });
   
   const docs2 = await partition1.view("example-query", "aview", {include_docs: true});
   
   const partition2 = db.partition('partition2');
   // A view can be used for each partition
   const docsFromPartition2 = await partition1.view("example-query", "aview", {include_docs: true});
   ```
   
   The new partition object would support all the `.find` and `.view` options to query with and internally would remember the name of the partition to use when querying.
   
   Currently we don't support _all_docs or changes.
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services