incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MK>
Subject Re: One view per "query"?
Date Fri, 10 Jun 2011 14:04:36 GMT
On Fri, 10 Jun 2011 12:05:20 +0200
Daniele Testa <> wrote:
> That would mean that I need 3*4=12 views to accomodate all those
> different "queries"?

Only if you have to have your application 100% served directly
from couch. However, IMO the view and shows make a lot more sense as
ancillary functions for use by an external server.   Working that way,
you could cover these twelve cases with a single view and a single
function in the server proper, or 3 views and a single function, or 3
views and 4 function functions in the server -- ie, you are free to
choose how to do it.  For example, if you want to maintain the least
amount of code, you'd go with the first option, a single view with a
map defined:

function (doc) {
	emit (doc.title, [doc.artist, doc.genre, doc.insert_date]);

Dead simple, returns an array of all albums keyed by title.  Your
server uses this like (js-esque pseudo code):

function (criteria, value, sortby) {
	var rawJSON = [whatever method you use to query couch];
	// most languages have a means of turning JSON strings into
	   data structures:
        var data = parse rawJSON;
	var selected; // array type
        for (e in data.rows) {
	// you could also use a map type function here if you or your
language have such
		if (data.rows.criteria == value) 
	return Sort(selected, sortby); 

How the "Sort" works depends on what lang you are programming in,
sortby would probably be a comparison (eg: a.title > b.title ? b : a).

If you want efficiency and you believe couch will do the most efficient
job of selected data (which it probably will in most settings), then you
might want the 3 views (these are all one liners, nb), and possibly
even 3 views and 4 ordering methods in the server.

>From this perspective, views and shows make a lot of sense and are very
useful -- they are like being able to incorporate simple, customized SQL
queries into an sql db, providing you with a nice separation of
concerns (you don't need any SQL in your server code, the db itself
incorporates a "design" specific to the form of its content). But
understood as the final points in a query, they just seem awkward, and
you have no such separation.

"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)

View raw message