couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hardtke <da...@cloudant.com>
Subject Re: View advice
Date Fri, 08 Apr 2011 17:12:10 GMT

Yes, you can use all of the available query options (starkey, endkey, 
stale, etc.) with the caveat that all views must be the same reduce type 
(true/false).  The reduce type is specified in the URL, not the form.



On 04/08/11 10: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 <david@cloudant.com> 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
>>> <peter.matulla@googlemail.com>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<olafura@olafura.com>
>>>> 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
>>>>> <pierrealexandre.lacerte@gmail.com>  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
>>>>
>>


Mime
View raw message