I'm new in CouchDB and I'm wondering if is possible and how is possible to sort a view in CouchDB.
PS: I'm using CouchDB 3.0.0
Yes, it is possible to sort views. In fact, all views are always sorted. It's impossible to not sort a view.
Each view is sorted according to the collation rules for the key emitted from the map function.
Related
I have some documents I would like to replicate to per user databases but only with a subset of fields on the main document. The "selector" option works great to easily select the docs I need but it does not appear to support the "fields" option. I can't find a way to do this without manually filtering the document fields on my node server, which seems quite inefficient.
It is not possible to replicate part of a document. The CouchDB replication mechanism is replicating the whole document as a unit.
I suggest you to review your document design in order to have a better fit with the replication requirements. Maybe it is more accurate to have two separate documents in your case.
I evaluating CouchDB & I'm wondering whether it's possible to achieve the following functionality.
I'm planning to develop a web application and the app should allow a 'parent' table and derivatives of this table. The parent table will contains all the fields (master table) and the user will selectively choose fields, which should be saved as separate tables.
My queries are as follows:
Is it possible to save different versions of the same table using CouchDB?
Is there an alternative to creating child tables (and clutter the database)?
I'm new to NoSQL databases and am evaluating CouchDB because it supports JSON out of the box and this format seems to fit the application very well.
If there are alternatives to NOT save the derivatives as separate tables, the better will the application be. Any ideas how I could achieve this?
Thanks in advance.
CouchDB is a document oriented database which means you cannot talk in terms of tables. There are only documents. The _rev (or revision ID) describes a version of a document.
In CouchDB, there are 2 ways to achieve relationships.
Use separate documents
Use an embedded array
If you do not prefer to clutter your database, you can choose to use option (2) by using an embedded array.
This gives you the ability to have cascade delete functionality as well for free.
Are Cloudant's concept of Indexes native to CouchDB? It appears the Cloudant has built their Index feature on top of CouchDB, is this correct? If so, what is the difference between an Index and a View?
The Query interface is (currently) a simplifying API for creating and accessing the undelying CouchDB views. The indexes you define via the _index endpoint are actually translated into views, and those views can be accessed and used in the same way as a normal CouchDB view, as well as via the _find endpoint (note: the inverse is not true - Query doesn't currently use existing javascript views). The views stay in the erlang layer so gives us the opportunity for performance enhancements etc.
You can also filter result data to only return document fields you're interested in, as opposed to hard coding the returned fields in the view or running the view result through a list function.
Cheers
Simon
I would like to know what are the best practices for storing heterogeneous data in CouchDB. In MongoDB you have collections which help with the modelling of the data (IE: Typical usage is one document type per collection). What is the best way to handle this kind of requirement in CouchDB? Tagging of documents with a _type field? Or is there some other method that I am not aware of?
Main benefit of Mongo's collection is that indexes are defined and calculated per collection. In case of Couch you have even more freedom and flexibility to do that. Each index is defined by the view in map/reduce way. You limit the data to calculate the index by filtering it in map function. Because of this flexibility, it is up to you how to distinguish which document belongs to which view.
If you really like the fixed Mongo-like style of division documents into set of distinct partitions with separate indexes just create the field collection and never mix two different collections in single view. In my opinion, rejecting one of the only benefit of Couch over Mongo (where Mougo is in general more powerful and flexible system) does not seem to be good idea.
I have a question about querying CouchDB.
I have a query that generates a set of outputs. These outputs are also the result of another query.
I want to define a CouchDB view permitting to get all the outputs (and the inputs of a specific document). Is it possible to get the results of a map function and consider them as un input of another map function ?
In SPARQL, I have do this query, it is modeled as follow :
SELECT ?linkedAction
WHERE { ?action nova:hasOutput ``doc-02-10-C''.
?action (nova:hasInput/^nova:hasOutput)* ?linkedAction.
}
Is it possible to do that in map/reduce ?
Best Regards.
Amin
You can try Couch-Incarnate.
Or use Cloudant chained mapreduce views (hopefully it will be integrated in CouchDB).
No, each view index is completely isolated from other views. (and other databases for that matter) CouchDB's incremental view updates would be impossible to keep efficient when changes from one view can affect another. You'll need to perform this kind of additional processing in your application layer.