couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Myung <dmy...@dimagi.com>
Subject Re: Change in date handling from 1.0.x to 1.2
Date Wed, 19 Sep 2012 20:08:19 GMT
My question stems around the fact that I did nothing to the design doc in
couch, but blew away the _design directory in the filesystem (*all* the
generated view files), and had to wait hours for it to regenerate only to
see the same incorrect result.

The expected behavior of adding the newline and subsequently altering the
view to force couch to recompute the views again makes sense - that was my
fallback.  Because I didn't need to "change" the view to get it to
regenerate, I thought deleting the _design directory would have the same
intended result. (because of the javascript library fix)


On Wed, Sep 19, 2012 at 4:01 PM, Nathan Vander Wilt <
nate-lists@calftrail.com> wrote:

> On Sep 18, 2012, at 9:02 PM, Daniel Myung wrote:
>
> > Is there some type of bytecode or something cached somewhere for design
> > docs for view functions that could possibly explain how my removal of the
> > _design directory could still yield the same original result?
> >
>
> Sorry, I don't have authoritative documentation references on this, but my
> understanding is that this is how it works:
>
> 1. Removing a _design document does not remove generated views, unless you
> run view cleanup
> 2. CouchDB stores generated views on disk based on a hash of the view's
> *code*
>
> One benefit of this is that in production you can rebuild a new view e.g.
> _design/app-new while still fetching old results from _design/app, then
> switch the names once the new view has caught up. (IIRC, there may also be
> some optimization within a _design doc so identical map functions can be
> reused between different reduction functions?)
>
> Anyway, it sounds like what happened is that because your view code didn't
> actually change (just its behaviour due to JS library differences) this
> edge case meant that CouchDB assumed your view was already caught up with
> most of your database's _changes. Adding a newline to the view did change
> its "identity", and so was a reasonable way to trigger view generation. The
> other way would have been, while your _design document was temporarily
> removed, to clean up views.
>
> hth,
> -natevw
>
>
>
>
> >
> > On Mon, Sep 17, 2012 at 9:18 PM, Paul Davis <paul.joseph.davis@gmail.com
> >wrote:
> >
> >> I agree with Bob. This is a difference in your Spidermonkey library.
> >>
> >> On Mon, Sep 17, 2012 at 5:47 PM, Robert Newson <rnewson@apache.org>
> 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 <czue@dimagi.com> 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
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message