incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <nate-li...@calftrail.com>
Subject Re: Change in date handling from 1.0.x to 1.2
Date Wed, 19 Sep 2012 20:39:03 GMT
On Sep 19, 2012, at 1:08 PM, Daniel Myung wrote:
> 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)

Ah, sorry. Misunderstood what you meant by deleting the .databasename_design folder. That
does seem strange, the only thing I can think of would be to check that your current configuration
is still storing the data in the expected place (or restart CouchDB in case it has a file
pointer open on the deleted view data that it somehow uses to re-link it??). I would think
that deleting the hidden _design folder for a database would be the ultimate form of view
cleanup, but perhaps someone else could chime in with more expertise in this area.

-nvw





> 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
View raw message