You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by David Coallier <da...@gmail.com> on 2010/01/27 19:21:03 UTC
Time processing difference between 0.11.0b898401 and 0.11.0b903617
Hey lads,
I'm suspecting a bug but before I report I was wondering if anyone was
aware of a change that would have happened between 0.11.0b898401 and
0.11.0b903617.
The problem is quite simple, I have a few on 0.11.0b898401 that pretty
much does that:
function(doc) {
var x = new Date(1264515335 * 1000);
emit(x, null);
}
Which outputs "2010-01-26T14:15:35Z" which is expected.
Then on the second server which is version: 0.11.0b903617 (Which is
also a replica of the first example -- continuous) if you run the same
function be it _temp or not:
function(doc) {
var x = new Date(1264515335 * 1000);
emit(x, null);
}
You get the {} as the key.
Anyone's got an idea what might have happened?
--
Slan,
David
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by David Coallier <da...@gmail.com>.
>
> $ js -v
> JavaScript-C 1.8.0 pre-release 1 2007-10-03
>
$ js -v
JavaScript-C 1.7.0 2007-10-03
And I have the same on both servers which I was testing from. The
working one (0.11.0b898401) and the weird one (0.11.0b903617)
--
Slan,
David
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Jan 27, 2010 at 5:37 PM, David Coallier
<da...@gmail.com> wrote:
>>
>> I just tested with my copy of trunk and this temp view:
>>
>> function(doc) {
>> var d = new Date("2010/02/04");
>> emit(d, null);
>> }
>>
>> I only have one doc, in there, so my rows are
>>
>> "2010-02-04T08:00:00.000Z", null
>>
>> Which to me looks like what I was expecting.
>>
>
> I have tried on a clean db with 1 document as well
> function(doc) {
> var d = new Date("2010/02/04");
> emit(d, null);
> }
>
> This emits
> {}, null
>
Hmm, something is up. Maybe you have a different SpiderMonkey version than me?
Mine:
$ js -v
JavaScript-C 1.8.0 pre-release 1 2007-10-03
> And from the log(d); I get
> Thu, 28 Jan 2010 01:28:38 GMT] [info] [<0.23547.0>] OS Process
> #Port<0.6750> Log :: {}
>
> I get the same with
> function(doc) {
> var d = new Date(1264515335 * 1000);
> emit(d, null);
> }
>
> ( http://skitch.com/davidcoallier/n1tmy )
>
> However, the interesting bits to note is that, even though this
> outputs {}, null I can still use the d (Date) object.
>
> function(doc) {
> var d = new Date(1264515335 * 1000);
> emit(d.getFullYear(), null);
> emit(d.getUTCMonth()+1, null);
> }
>
> I get:
>
> 2010, null
> 1, null
>
> Or ( http://skitch.com/davidcoallier/n1tks/apache-couchdb-futon-browse-database
> )
>
>
>
>
>> That doesn't explain your {} though. Maybe it is the result of parsing
>> an invalidate date format? you can use log() in your functions to
>> output to the couch.log (at info level)
>>
>> Maybe you have an undefined that used to be silently ignored but now
>> is trying to serialize and coming out with {}?
>>
>
> The undefined is out of the equation considering that I check for date
> validity and field presence. However as you can see up there, this
> happens as well when I execute on a single document database as well.
>
>
>
> --
> Slan,
> David
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by David Coallier <da...@gmail.com>.
>
> I just tested with my copy of trunk and this temp view:
>
> function(doc) {
> var d = new Date("2010/02/04");
> emit(d, null);
> }
>
> I only have one doc, in there, so my rows are
>
> "2010-02-04T08:00:00.000Z", null
>
> Which to me looks like what I was expecting.
>
I have tried on a clean db with 1 document as well
function(doc) {
var d = new Date("2010/02/04");
emit(d, null);
}
This emits
{}, null
And from the log(d); I get
Thu, 28 Jan 2010 01:28:38 GMT] [info] [<0.23547.0>] OS Process
#Port<0.6750> Log :: {}
I get the same with
function(doc) {
var d = new Date(1264515335 * 1000);
emit(d, null);
}
( http://skitch.com/davidcoallier/n1tmy )
However, the interesting bits to note is that, even though this
outputs {}, null I can still use the d (Date) object.
function(doc) {
var d = new Date(1264515335 * 1000);
emit(d.getFullYear(), null);
emit(d.getUTCMonth()+1, null);
}
I get:
2010, null
1, null
Or ( http://skitch.com/davidcoallier/n1tks/apache-couchdb-futon-browse-database
)
> That doesn't explain your {} though. Maybe it is the result of parsing
> an invalidate date format? you can use log() in your functions to
> output to the couch.log (at info level)
>
> Maybe you have an undefined that used to be silently ignored but now
> is trying to serialize and coming out with {}?
>
The undefined is out of the equation considering that I check for date
validity and field presence. However as you can see up there, this
happens as well when I execute on a single document database as well.
--
Slan,
David
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Jan 27, 2010 at 12:41 PM, David Coallier
<da...@gmail.com> wrote:
>> Can you try with r902422?
>>
I just tested with my copy of trunk and this temp view:
function(doc) {
var d = new Date("2010/02/04");
emit(d, null);
}
I only have one doc, in there, so my rows are
"2010-02-04T08:00:00.000Z", null
Which to me looks like what I was expecting.
That doesn't explain your {} though. Maybe it is the result of parsing
an invalidate date format? you can use log() in your functions to
output to the couch.log (at info level)
Maybe you have an undefined that used to be silently ignored but now
is trying to serialize and coming out with {}?
Chris
>> If this is a consequence of the json2.js change, we'll have to fix it.
>
>
> I believe this is a consequence of json2.js as well (At least that's
> the only difference that deals with time related matter that I could
> identify).
>
> In fact how I fixed my code for now since this is a prod server is:
> http://friendpaste.com/3VFWC3DftLPeplmusvdeUg
>
> I'll try with 902422 and let you know.
>
>
>
> --
> Slan,
> David
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by David Coallier <da...@gmail.com>.
> Can you try with r902422?
>
> If this is a consequence of the json2.js change, we'll have to fix it.
I believe this is a consequence of json2.js as well (At least that's
the only difference that deals with time related matter that I could
identify).
In fact how I fixed my code for now since this is a prod server is:
http://friendpaste.com/3VFWC3DftLPeplmusvdeUg
I'll try with 902422 and let you know.
--
Slan,
David
Re: Time processing difference between 0.11.0b898401 and
0.11.0b903617
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Jan 27, 2010 at 10:21 AM, David Coallier
<da...@gmail.com> wrote:
> Hey lads,
>
> I'm suspecting a bug but before I report I was wondering if anyone was
> aware of a change that would have happened between 0.11.0b898401 and
> 0.11.0b903617.
Can you try with r902422?
If this is a consequence of the json2.js change, we'll have to fix it.
Thanks,
Chris
>
> The problem is quite simple, I have a few on 0.11.0b898401 that pretty
> much does that:
>
> function(doc) {
> var x = new Date(1264515335 * 1000);
> emit(x, null);
> }
>
>
> Which outputs "2010-01-26T14:15:35Z" which is expected.
>
> Then on the second server which is version: 0.11.0b903617 (Which is
> also a replica of the first example -- continuous) if you run the same
> function be it _temp or not:
> function(doc) {
> var x = new Date(1264515335 * 1000);
> emit(x, null);
> }
>
> You get the {} as the key.
>
> Anyone's got an idea what might have happened?
>
> --
> Slan,
> David
>
--
Chris Anderson
http://jchrisa.net
http://couch.io