Afaik, you can only POST a body of this form at present; -d '{"keys":["foo", "bar"]} B. On 8 April 2011 18:02, Keith Gable wrote: > That's exactly what I'm suggesting FWIW. Didn't know that was possible... > Does that let you specify startkey/endkey instead of key? > > > > On Apr 8, 2011, at 11:27 AM, David Hardtke wrote: > >> >> You can send multiple keys to the view if you use POST: >> >> POST /db/_design/ddoc/_view/name?reduce=true/false -d >> '{"queries":[{"key":"NY"},{"key","CA"}]}' >> >> You'll still need to remove duplicates and merge the two views for the two >> keys. >> >> On 04/08/11 04:39, Daniel Itaboraí wrote: >>> >>> I would love to be able to do union operations like Keith described and I >>> would love even more to be able to send a javascript function to a view. >>> That function would then filter out the documents based on whatever >>> criteria >>> I want, something like >>> >>> function(doc) { >>>    // returns true to those documents I want to retrieve >>>    return doc.type == "Article"&&  (doc.location == "NY" || doc.location >>> == >>> "CA" ); >>> } >>> >>> You probably don´t even need the whole doc, filtering solely based on the >>> emitted keys through the function could do the trick. You´d still have to >>> specify an appropriate key range to speed up things though. >>> >>> This would screw up the reduce results stored on the Btree, but I feel >>> that >>> "view limited ad hoc querying" is such an important thing, that I would >>> forgo the speed of reduce in these cases. >>> >>> Simple things should be possible, even if they conflict with design >>> goals. >>> >>> Daniel >>> >>> On Fri, Apr 8, 2011 at 6:53 AM, Peter Matulla >>> wrote: >>> >>>> another approach: >>>> >>>> >>>> http://www.vertigrated.com/blog/2010/04/generic-ad-hoc-queries-in-couchdb/ >>>> >>>> Peter >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -------- Original Message  -------- >>>> Subject: Re: View advice >>>> From: Olafur Arason >>>> To: user@couchdb.apache.org >>>> Date: Freitag, 8. April 2011 07:57:25 >>>> >>>>> You can fake it if you want: >>>>> >>>>> function(doc) { >>>>>  if(doc.type == "Article"&&  (doc.location == "NY" || doc.location == >>>> >>>> "CA" )){ >>>>> >>>>>    emit(["NYCA", doc.release_date], doc) >>>>>  } >>>>> } >>>>> >>>>> Or join the discussion about why views should have search fields so >>>>> this >>>> >>>> could >>>>> >>>>> be resolved once and for all. >>>>> >>>>> They it would be: >>>>> >>>>> function(doc) { >>>>>  if(doc.type == "Article" )){ >>>>>    emit(doc.release_date, doc, doc.location) >>>>>  } >>>>> } >>>>> >>>>> then query it with: >>>>> >>>>> _view/articles?limit=5&decending=true&search="NY OR CA" >>>>> >>>>> Btw you only need this to call it from couchapp. It's better not to >>>>> have >>>> >>>> the >>>>> >>>>> whole url so you can easily change hosts and even database names >>>>> like application-test. >>>>> >>>>> There is some work going on in this direction and it's important to let >>>> >>>> people >>>>> >>>>> know that this is important. >>>>> >>>>> Regards, >>>>> Olafur Arason >>>>> >>>>> On Fri, Apr 8, 2011 at 03:13, Pierre-Alexandre Lacerte >>>>>  wrote: >>>>>> >>>>>> I am currently trying to create a view to reproduce this SQL query: >>>>>> >>>>>> SELECT * FROM articles WHERE articles.location="NY" OR >>>> >>>> articles.location="CA" ORDER BY articles.release_date DESC >>>>>> >>>>>> I tried to create a view with a complex key: function(doc) { >>>>>> if(doc.type >>>> >>>> == "Article") { emit([doc.location, doc.release_date], doc) } } >>>>>> >>>>>> And then using startkey and endkey to retrieve one location and >>>>>> ordering >>>> >>>> the result on the release date. >>>>>> >>>> >>>> http://myhost.com:8000/mydb/_design/application/_view/articles?startkey=["NY", >>>> {}]&endkey=["NY"]&limit=5&descending=true >>>>>> >>>>>> This works fine. >>>>>> >>>>>> However, I learned that I cannot send multiple startkeys and endkeys >>>>>> to >>>> >>>> my view. (To mimic WHERE articles.location="NY" OR >>>> articles.location="CA") >>>>>> >>>>>> How should I design this? (It could happen that I would need to query >>>> >>>> for 15 different locations) >>>>>> >>>>>> So far, I have 3 suggestions: >>>>>> 1- Store the view output in its own database, and make a new view to >>>> >>>> sort by release date. I'm not sure if this option will be fast and scale >>>> well... >>>>>> >>>>>> 2- Use couchdb-lucene. >>>>>> 3- Hack my version to support multiple startkeys or endkeys. >>>> >>>> https://issues.apache.org/jira/browse/COUCHDB-523 >>>>>> >>>>>> Thanks for your help, >>>>>> >>>>>> Pierre >>>> >> >