Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YAEJFt5ERnHBXhm8R1_cPepjA9XoLRfkR+U4Ly26vCk9Q@mail.gmail.com>
References: 
 <CAF+m3taUVT7-QEcsFYN-B+UQJ0YYiyn4uworJDMXDEd_Mx6SxA@mail.gmail.com>
	<CABvT1DGDm0F=jBKZLRNMnBn057QohjR2RzR0+Voiyrs0d7QKRQ@mail.gmail.com>
	<CAJ_m3YAEJFt5ERnHBXhm8R1_cPepjA9XoLRfkR+U4Ly26vCk9Q@mail.gmail.com>
Date: Wed, 19 Sep 2012 00:02:20 -0400
Message-ID: 
 <CAJfs-5CPLJCC5t-4xh=EgJPOHbD-PEBEw8u6O92kzdck1J-BJw@mail.gmail.com>
Subject: Re: Change in date handling from 1.0.x to 1.2
From: Daniel Myung <dmyung@dimagi.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf307ca418cd495404ca061298

--20cf307ca418cd495404ca061298
Content-Type: text/plain; charset=ISO-8859-1

Hi all, (replying on behalf of cory)

Thanks to the suggestions on that - that indeed was the issue for us. It
wasn't without some quirks along the way to get our results running
correctly.

*tl;dr*: New library fixed it, but initial run at the full reindex still
had the nulls coming out in our results!

*Full story:*
We did a rebuild of couch 1.2 and got the right js185 lib compiled along
with it. I knew it was the right lib setup because i ran into some issues
with the LD_LIBRARY_PATH that was fixed with an entry in /etc/ld.so.conf.d/

Anyway, i deleted the .database_design/ directory and did a full reindex of
the database (which took some time).

Much to my horror after that long wait, the view's results were still
giving us null values for the variable that was trying to parse the date
timestamp!

To make sure I wasn't going insane, I copied a doc from that db and pasted
it into a new db and ran the same view code - result? keys
were correctly showing the parsed date values. (I did this initially too to
verify the jslib was working as expected)

Question: What could possibly have caused the entire view operation to
return the original incorrect result?

 * I deleted the database's _design directory
 * I'm fairly certain that the *new *jslib was running this reindex. The
/etc/ld/so.conf.d/ fix was required on our RHEL6 install as I was getting
os error 127s with no progress on our view refreshes on initial runs.
 * restarted couchdb as well to verify ld config.
 * I ran a preindex_views via couchdbkit - but that populated it into a
regenerated _design directory
 * I also made a new db beforehand with 1 doc with the view function pasted
in futon temp view to verify the lib was working.

What finally got the view to work correctly again was I went into the
design doc, and added a newline to the view function manually within the
design doc itself and forced a view reindex by hitting the view in futon.
 No config change/reboot or anything on the couch server except that design
doc change.

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?

(the database file itself is replicated from a 1.0 instance)

I realize that this is an odd corner case - but thought it might be worth
noting it somewhere :)

Dan


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
>

--20cf307ca418cd495404ca061298--