Re: Wildcard search on startkey and endkey
Hi Pulkit,
> Is it possible to do a search using startkey and endkey in v1.2.0 where the
> beginning elements could be anything? Like this:
> startkey=[ {}, {}, {}, "elem4name", "elem5name" ]
No. Think about the view index as a set of cards in a card sorter. You need to
know where to start searching.
If you need to search a card according to elem4name and elem5name, build a view
for that.
> With a compound key being spit out by a MAP as follows:
> emit ( [elem1, elem2, elem3, elem4, elem5], doc);
Please note that you never need to emit the document.
You can "emit([elem1, elem2, elem3, elem4, elem5], null)"
and then get the view with "include_docs=true".
You'll get a smaller index on disk and I suppose you will need less memory and
CPU to handle it.
Regards,
Aurélien
Re: Wildcard search on startkey and endkey
CouchDB is a lot easier to understand if you think about querying views
alphabetically like a card catalog. You can say "AA to BZ" but you cannot
say "*A to *Z".
That said, CouchDB Lucene is actually built for those kinds of queries (and
more) and it is really simple to use. Try it out.
On Sep 17, 2012 11:52 PM, "Pulkit Singhal" wrote:
> With a compound key being spit out by a MAP as follows:
> emit ( [elem1, elem2, elem3, elem4, elem5], doc);
>
> Is it possible to do a search using startkey and endkey in v1.2.0 where the
> beginning elements could be anything? Like this:
> startkey=[ {}, {}, {}, "elem4name", "elem5name" ]
>
> Thoughts?
>
Re: Change in date handling from 1.0.x to 1.2
I agree with Bob. This is a difference in your Spidermonkey library. On Mon, Sep 17, 2012 at 5:47 PM, Robert Newson wrote: > I think it's to do with the version of Spidermonkey you've used, > rather than CouchDB version. > > B. > > On 17 September 2012 23:35, Cory Zue wrote: >> Hi, >> >> We're in the process of migrating our app from couch 1.0 to 1.2. >> Seeing different behavior in this view function though, which is >> giving us some trouble. >> >> https://github.com/dimagi/core-hq/blob/master/corehq/couchapps/formtrends/views/form_time_by_user/map.js >> >> It looks like it works as designed in 1.0 but in 1.2 >> submit_time.getDay() and submit_time.getHours() both return null. >> >> Is there a better way to handle this now? >> >> Our dates are formatted like this: 2011-03-07T20:27:12Z >> >> Cory
Re: Change in date handling from 1.0.x to 1.2
I think it's to do with the version of Spidermonkey you've used, rather than CouchDB version. B. On 17 September 2012 23:35, Cory Zue wrote: > Hi, > > We're in the process of migrating our app from couch 1.0 to 1.2. > Seeing different behavior in this view function though, which is > giving us some trouble. > > https://github.com/dimagi/core-hq/blob/master/corehq/couchapps/formtrends/views/form_time_by_user/map.js > > It looks like it works as designed in 1.0 but in 1.2 > submit_time.getDay() and submit_time.getHours() both return null. > > Is there a better way to handle this now? > > Our dates are formatted like this: 2011-03-07T20:27:12Z > > Cory
Change in date handling from 1.0.x to 1.2
Hi, We're in the process of migrating our app from couch 1.0 to 1.2. Seeing different behavior in this view function though, which is giving us some trouble. https://github.com/dimagi/core-hq/blob/master/corehq/couchapps/formtrends/views/form_time_by_user/map.js It looks like it works as designed in 1.0 but in 1.2 submit_time.getDay() and submit_time.getHours() both return null. Is there a better way to handle this now? Our dates are formatted like this: 2011-03-07T20:27:12Z Cory
