You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@tumbolia.org> on 2012/02/10 01:52:38 UTC
[VOTE] Apache CouchDB 1.2.0 release, first round
Hello,
I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
We encourage the whole community to download and test these release
artifacts so that any critical issues can be resolved before the release is
made. Everyone is free to vote on this release, so get stuck in!
We are voting on the following release artifacts:
http://people.apache.org/~nslater/dist/1.2.0/
These artifacts have been built from the following tree-ish in Git:
cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
Please follow the test procedure before voting:
http://wiki.apache.org/couchdb/Test_procedure
Thank you.
Happy voting,
N
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
make check & js tests pass
make distcheck ok
md5 & sh1 signatures OK
noticed the same error in CHANGES and dev about versionning.The
warning also apppears in 1.1.2 line .
- 1 .
- benoît
On Thu, Feb 9, 2012 at 4:52 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/1.2.0/
>
>
> These artifacts have been built from the following tree-ish in Git:
>
> cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
>
>
> Please follow the test procedure before voting:
>
> http://wiki.apache.org/couchdb/Test_procedure
>
>
> Thank you.
>
> Happy voting,
>
> N
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Should I remove the whole section for 1.1.2? (My guess is yes.)
On Fri, Feb 10, 2012 at 8:08 PM, Noah Slater <ns...@tumbolia.org> wrote:
> As in, within a few hours, preferably.
>
>
> On Fri, Feb 10, 2012 at 8:06 PM, Randall Leeds <ra...@gmail.com>wrote:
>
>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>> >
>> > On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>> > > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>> > > and I asked around. If memory serves, Randall happened to be on at the
>> > > time and he asked me the same question you just did. I said I never
>> > > saw an RFC email and that's when he realized it was not done publicly.
>> >
>> > I was aware the entire time, but I think the motivation is sound and
>> > it needed to be done. A couple committers spoke up to say we didn't
>> > think it was sensitive enough to warrant the private discussion but
>> > ultimately there was broad consensus on the implementation and the
>> > change itself. One of those (let us all celebrate) extremely rare
>> > times where there wasn't opportunity for broad community input.
>> >
>> > Creating a view on _users that pulls the relevant parts of a user
>> > document out is the way forward for public profiles, I think.
>> > If someone would write a blog post showing how that works it'd be
>> > great. In retrospect this would have been a great thing to do weeks
>> > ago. Lesson learned.
>>
>> Just to be clear I don't want to dismiss your concerns. If you believe
>> this
>> needs a config option rather than just documentation now is a good time to
>> speak up loudly since the vote was aborted.
>>
>> >
>> > Now to test!
>> >
>> > -R
>> >
>> > >
>> > > I am pleased and grateful for the 1.2 release. It's remarkable! I'll
>> > > simply remind the community, don't email a plus-one just because the
>> > > unit tests pass. Install your application! Test your application! If
>> > > you use _users in your Couch app, this will be the most significant
>> > > breaking change since the 0.9 release.
>> > >
>> > > On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> > >> Did you bring this up on the RFC thread or in private, Jason?
>> > >>
>> > >> On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com>
>> wrote:
>> > >>
>> > >>> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> > >>> > Hello,
>> > >>> >
>> > >>> > I would like call a vote for the Apache CouchDB 1.2.0 release,
>> first
>> > >>> round.
>> > >>>
>> > >>> Documents in the _users database are no longer publicly readable.
>> > >>>
>> > >>> I understand that there was no public RFC about this due to its
>> > >>> security implications?
>> > >>>
>> > >>> Iris Couch users have been running the 1.2.x beta builds for a few
>> > >>> ekes and this is the top point of feedback. People have to rewrite
>> > >>> their Couch apps, in particular because most of Chris's projects and
>> > >>> examples uses _user to keep public profiles (nickname, Gravatar URL,
>> > >>> etc.).
>> > >>>
>> > >>> I suppose this is old news. The decision is good. It's a documented
>> > >>> breaking change. Fine. I hope there isn't blowback though.
>> > >>>
>> > >>> --
>> > >>> Iris Couch
>> > >>>
>> > >
>> > >
>> > >
>> > > --
>> > > Iris Couch
>>
>
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
As in, within a few hours, preferably.
On Fri, Feb 10, 2012 at 8:06 PM, Randall Leeds <ra...@gmail.com>wrote:
> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
> >
> > On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
> > > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
> > > and I asked around. If memory serves, Randall happened to be on at the
> > > time and he asked me the same question you just did. I said I never
> > > saw an RFC email and that's when he realized it was not done publicly.
> >
> > I was aware the entire time, but I think the motivation is sound and
> > it needed to be done. A couple committers spoke up to say we didn't
> > think it was sensitive enough to warrant the private discussion but
> > ultimately there was broad consensus on the implementation and the
> > change itself. One of those (let us all celebrate) extremely rare
> > times where there wasn't opportunity for broad community input.
> >
> > Creating a view on _users that pulls the relevant parts of a user
> > document out is the way forward for public profiles, I think.
> > If someone would write a blog post showing how that works it'd be
> > great. In retrospect this would have been a great thing to do weeks
> > ago. Lesson learned.
>
> Just to be clear I don't want to dismiss your concerns. If you believe this
> needs a config option rather than just documentation now is a good time to
> speak up loudly since the vote was aborted.
>
> >
> > Now to test!
> >
> > -R
> >
> > >
> > > I am pleased and grateful for the 1.2 release. It's remarkable! I'll
> > > simply remind the community, don't email a plus-one just because the
> > > unit tests pass. Install your application! Test your application! If
> > > you use _users in your Couch app, this will be the most significant
> > > breaking change since the 0.9 release.
> > >
> > > On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> > >> Did you bring this up on the RFC thread or in private, Jason?
> > >>
> > >> On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com>
> wrote:
> > >>
> > >>> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> > >>> > Hello,
> > >>> >
> > >>> > I would like call a vote for the Apache CouchDB 1.2.0 release,
> first
> > >>> round.
> > >>>
> > >>> Documents in the _users database are no longer publicly readable.
> > >>>
> > >>> I understand that there was no public RFC about this due to its
> > >>> security implications?
> > >>>
> > >>> Iris Couch users have been running the 1.2.x beta builds for a few
> > >>> ekes and this is the top point of feedback. People have to rewrite
> > >>> their Couch apps, in particular because most of Chris's projects and
> > >>> examples uses _user to keep public profiles (nickname, Gravatar URL,
> > >>> etc.).
> > >>>
> > >>> I suppose this is old news. The decision is good. It's a documented
> > >>> breaking change. Fine. I hope there isn't blowback though.
> > >>>
> > >>> --
> > >>> Iris Couch
> > >>>
> > >
> > >
> > >
> > > --
> > > Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 3:23 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
> The reasoning behind was that only admins should be encouraged to see
> the list of all users. Like on a OS you can't see the lists of users
> instead you're an admin. (you can eventually see the list of connected
> users but that another topic.
>
> Instead of allowoing changes in users dbs (witch shouldn't really be
> exposed ) i think a better behavior would be to have a separate dbs to
> shows some users and eventually their profile.
>
s/dbs/db
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Feb 11, 2012 at 10:04 PM, Randall Leeds <ra...@gmail.com> wrote:
> Huh...
>
> On Feb 10, 2012 7:01 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>
>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com>
> wrote:
>> > On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>> >>
>> >> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>> >> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>> >> > and I asked around. If memory serves, Randall happened to be on at
> the
>> >> > time and he asked me the same question you just did. I said I never
>> >> > saw an RFC email and that's when he realized it was not done
> publicly.
>> >>
>> >> I was aware the entire time, but I think the motivation is sound and
>> >> it needed to be done. A couple committers spoke up to say we didn't
>> >> think it was sensitive enough to warrant the private discussion but
>> >> ultimately there was broad consensus on the implementation and the
>> >> change itself. One of those (let us all celebrate) extremely rare
>> >> times where there wasn't opportunity for broad community input.
>> >>
>> >> Creating a view on _users that pulls the relevant parts of a user
>> >> document out is the way forward for public profiles, I think.
>> >> If someone would write a blog post showing how that works it'd be
>> >> great. In retrospect this would have been a great thing to do weeks
>> >> ago. Lesson learned.
>> >
>> > Just to be clear I don't want to dismiss your concerns. If you believe
> this
>> > needs a config option rather than just documentation now is a good time
> to
>> > speak up loudly since the vote was aborted.
>>
>> Thanks. I am concerned. To me, the change is noteworthy but not a
> showstopper.
>>
>> I tested your suggestion, however I do not think it is possible.
>> Non-admins cannot access a view.
>
> That's news to me. I didn't catch that before. Is this necessary for any
> reason? Shouldn't the design actions themselves enforce whatever they need
> to?
>
The reasoning behind was that only admins should be encouraged to see
the list of all users. Like on a OS you can't see the lists of users
instead you're an admin. (you can eventually see the list of connected
users but that another topic.
Instead of allowoing changes in users dbs (witch shouldn't really be
exposed ) i think a better behavior would be to have a separate dbs to
shows some users and eventually their profile.
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
I resemble that remark.
On Sun, Feb 12, 2012 at 2:53 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Sun, Feb 12, 2012 at 9:23 AM, Noah Slater <ns...@tumbolia.org> wrote:
> > Wait, what?
> >
> > You were actually using a sock puppet to lend support to your own
> > suggestions?
> >
> > Surely, I am missing something?
>
> Only the humour of the thing.
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 9:23 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Wait, what?
>
> You were actually using a sock puppet to lend support to your own
> suggestions?
>
> Surely, I am missing something?
Only the humour of the thing.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Wait, what?
You were actually using a sock puppet to lend support to your own
suggestions?
Surely, I am missing something?
On Sun, Feb 12, 2012 at 2:19 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Sun, Feb 12, 2012 at 9:17 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> > On Sun, Feb 12, 2012 at 2:47 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >> Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
> >> for 1.2.0 either. It could go in 1.2.1.
> >>
> > failed to use another pseudo?
>
> Busted! :)
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 9:17 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Feb 12, 2012 at 2:47 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
>> for 1.2.0 either. It could go in 1.2.1.
>>
> failed to use another pseudo?
Busted! :)
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 2:47 AM, Jason Smith <jh...@iriscouch.com> wrote:
> Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
> for 1.2.0 either. It could go in 1.2.1.
>
failed to use another pseudo?
-benoit
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
It would require further modifying the new "system database"
implementation, effectively to allow me to view (1) my document only,
and (2) not any other documents, UNLESS, (3) it is a design document
and I am hitting a view.
This is a security-sensitvie piece of code and not something to be rushed.
Finally, there is the question of community buy-in.
On Sun, Feb 12, 2012 at 9:00 AM, Noah Slater <ns...@tumbolia.org> wrote:
> How quickly could we get it in? Hours, days?
>
> On Sun, Feb 12, 2012 at 1:47 AM, Jason Smith <jh...@iriscouch.com> wrote:
>
>> Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
>> for 1.2.0 either. It could go in 1.2.1.
>>
>> On Sun, Feb 12, 2012 at 8:45 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> > Since _users is the only database of this kind (_replicator uses a
>> > different policy, right?) I agree with you. _design/_auth should have
>> > a view that everyone can access. I'm unsure but at the moment I'm
>> > thinking a view that you can simply activate via Futon.
>> >
>> > function(doc) {
>> > // User-serviceable code
>> > var enabled = false // Set to true to reveal usernames
>> > var whitelist = [] // Add keys to reveal here.
>> >
>> > // Not user-serviceable code
>> > if(!enabled)
>> > return
>> >
>> > var val = {}
>> > whitelist.forEach(function(key) {
>> > if(key in doc)
>> > val[key] = doc[key]
>> > })
>> >
>> > emit(doc._id, val)
>> > }
>>
>> --
>> Iris Couch
>>
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
How quickly could we get it in? Hours, days?
On Sun, Feb 12, 2012 at 1:47 AM, Jason Smith <jh...@iriscouch.com> wrote:
> Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
> for 1.2.0 either. It could go in 1.2.1.
>
> On Sun, Feb 12, 2012 at 8:45 AM, Jason Smith <jh...@iriscouch.com> wrote:
> > Since _users is the only database of this kind (_replicator uses a
> > different policy, right?) I agree with you. _design/_auth should have
> > a view that everyone can access. I'm unsure but at the moment I'm
> > thinking a view that you can simply activate via Futon.
> >
> > function(doc) {
> > // User-serviceable code
> > var enabled = false // Set to true to reveal usernames
> > var whitelist = [] // Add keys to reveal here.
> >
> > // Not user-serviceable code
> > if(!enabled)
> > return
> >
> > var val = {}
> > whitelist.forEach(function(key) {
> > if(key in doc)
> > val[key] = doc[key]
> > })
> >
> > emit(doc._id, val)
> > }
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
Hi, Jason. Excellent idea! However I wouldn't say that is a blocker
for 1.2.0 either. It could go in 1.2.1.
On Sun, Feb 12, 2012 at 8:45 AM, Jason Smith <jh...@iriscouch.com> wrote:
> Since _users is the only database of this kind (_replicator uses a
> different policy, right?) I agree with you. _design/_auth should have
> a view that everyone can access. I'm unsure but at the moment I'm
> thinking a view that you can simply activate via Futon.
>
> function(doc) {
> // User-serviceable code
> var enabled = false // Set to true to reveal usernames
> var whitelist = [] // Add keys to reveal here.
>
> // Not user-serviceable code
> if(!enabled)
> return
>
> var val = {}
> whitelist.forEach(function(key) {
> if(key in doc)
> val[key] = doc[key]
> })
>
> emit(doc._id, val)
> }
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 4:04 AM, Randall Leeds <ra...@gmail.com> wrote:
> Huh...
>
> On Feb 10, 2012 7:01 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>
>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com>
> wrote:
>> > On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>> >>
>> >> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>> >> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>> >> > and I asked around. If memory serves, Randall happened to be on at
> the
>> >> > time and he asked me the same question you just did. I said I never
>> >> > saw an RFC email and that's when he realized it was not done
> publicly.
>> >>
>> >> I was aware the entire time, but I think the motivation is sound and
>> >> it needed to be done. A couple committers spoke up to say we didn't
>> >> think it was sensitive enough to warrant the private discussion but
>> >> ultimately there was broad consensus on the implementation and the
>> >> change itself. One of those (let us all celebrate) extremely rare
>> >> times where there wasn't opportunity for broad community input.
>> >>
>> >> Creating a view on _users that pulls the relevant parts of a user
>> >> document out is the way forward for public profiles, I think.
>> >> If someone would write a blog post showing how that works it'd be
>> >> great. In retrospect this would have been a great thing to do weeks
>> >> ago. Lesson learned.
>> >
>> > Just to be clear I don't want to dismiss your concerns. If you believe
> this
>> > needs a config option rather than just documentation now is a good time
> to
>> > speak up loudly since the vote was aborted.
>>
>> Thanks. I am concerned. To me, the change is noteworthy but not a
> showstopper.
>>
>> I tested your suggestion, however I do not think it is possible.
>> Non-admins cannot access a view.
>
> That's news to me. I didn't catch that before. Is this necessary for any
> reason? Shouldn't the design actions themselves enforce whatever they need
> to?
Since _users is the only database of this kind (_replicator uses a
different policy, right?) I agree with you. _design/_auth should have
a view that everyone can access. I'm unsure but at the moment I'm
thinking a view that you can simply activate via Futon.
function(doc) {
// User-serviceable code
var enabled = false // Set to true to reveal usernames
var whitelist = [] // Add keys to reveal here.
// Not user-serviceable code
if(!enabled)
return
var val = {}
whitelist.forEach(function(key) {
if(key in doc)
val[key] = doc[key]
})
emit(doc._id, val)
}
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Randall Leeds <ra...@gmail.com>.
Huh...
On Feb 10, 2012 7:01 PM, "Jason Smith" <jh...@iriscouch.com> wrote:
>
> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com>
wrote:
> > On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
> >>
> >> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
> >> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
> >> > and I asked around. If memory serves, Randall happened to be on at
the
> >> > time and he asked me the same question you just did. I said I never
> >> > saw an RFC email and that's when he realized it was not done
publicly.
> >>
> >> I was aware the entire time, but I think the motivation is sound and
> >> it needed to be done. A couple committers spoke up to say we didn't
> >> think it was sensitive enough to warrant the private discussion but
> >> ultimately there was broad consensus on the implementation and the
> >> change itself. One of those (let us all celebrate) extremely rare
> >> times where there wasn't opportunity for broad community input.
> >>
> >> Creating a view on _users that pulls the relevant parts of a user
> >> document out is the way forward for public profiles, I think.
> >> If someone would write a blog post showing how that works it'd be
> >> great. In retrospect this would have been a great thing to do weeks
> >> ago. Lesson learned.
> >
> > Just to be clear I don't want to dismiss your concerns. If you believe
this
> > needs a config option rather than just documentation now is a good time
to
> > speak up loudly since the vote was aborted.
>
> Thanks. I am concerned. To me, the change is noteworthy but not a
showstopper.
>
> I tested your suggestion, however I do not think it is possible.
> Non-admins cannot access a view.
That's news to me. I didn't catch that before. Is this necessary for any
reason? Shouldn't the design actions themselves enforce whatever they need
to?
>
> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
>
{"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>
> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
> HTTP/1.1 403 Forbidden
> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
> Date: Sat, 11 Feb 2012 02:57:43 GMT
> Content-Type: text/plain; charset=utf-8
> Content-Length: 102
> Cache-Control: must-revalidate
>
> {"error":"forbidden","reason":"Only admins can access design document
> actions for system databases."}
>
> --
> Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 13, 2012 at 12:32 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Mon, Feb 13, 2012 at 3:09 AM, <ro...@gmail.com> wrote:
>>> I've been following this thread with interest and concern.
>>>
>>> None of you will know me, so let me first say I'm a Couch end user and
>>> developer - and a huge fan of the technology who is worried about the
>>> future direction of Couch following the Couchbase debacle.
>>>
>>> Regardless of the subtleties, what the RFC might say, what other systems
>>> might do, to me it seems a screaming fundamental that what I put in to the
>>> data store is what comes back from it.
>>>
>>> If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1,
>>> 1.0000000000000000000000001 or anything other than exactly the same
>>> document that I stored in the first place.
>>>
>>> Same goes for storing 1
>>>
>>> I expect to get back 1, not 1.0 or any other mangled version regardless of
>>> how arguably mathematically equivalent it might be.
>>>
>>> So rule 1 has to be, whatever I put in, I get back.
>>>
>>> What happens at a view level is different. If I've stored 1.0 or 1 as a
>>> numeric (ie non-string) value, then what happens in the javascript of a
>>> view is more flexible. Here I'm living in the real world of nasty floats
>>> etc and in this case my view code should take appropriate care of what the
>>> number might actually be. I'd kind of expect anything with a decimal point
>>> to be interpreted as a float and anything without one to be interpreted as
>>> an integer. That seems pretty basic and easy to understand.
>>>
>>> Apologies if I'm missing the point - and obviously I'm new around here, but
>>> the one inviolable point to me seems to be that whatever I store, I should
>>> get back unchanged. Period. If we break that, we're no longer a data store.
>>>
>>> Roger
>>
>> Roger,
>>
>> Welcome!
>>
>> The issue here is how we define "same". Given your examples you appear
>> to be arguing for byte level equivalence between input and output.
>> While this may seem quite logical and even perhaps a necessity for
>> something that calls itself a datastore, its not how the world works.
>> Rather than convince you, I'll just show two examples:
>>
>> psql (9.0.5, server 9.0.3)
>> Type "help" for help.
>>
>> davisp=# create table foo(bar REAL);
>> CREATE TABLE
>> davisp=# insert into foo(bar) values(1.00000000000000000001);
>> INSERT 0 1
>> davisp=# select * from foo;
>> bar
>> -----
>> 1
>> (1 row)
>>
>> SQLite version 3.7.7 2011-06-25 16:35:41
>> Enter ".help" for instructions
>> Enter SQL statements terminated with a ";"
>> sqlite> create table foo(bar REAL);
>> sqlite> insert into foo(bar) values(1.00000000000000000001);
>> sqlite> select * from foo;
>> 1.0
>>
>> I'd try MySQL but I bet it returns 2.89 because of some bug.
>>
>> Anyway, my the point is that datastores do change the representation
>> of data inserted into them and will have differences in the output
>> returned.
>>
>> So while some may consider this a screaming fundamental, its really a
>> whole lot more complicated.
>>
>> In the end, as we've constantly repeated, anyone that wants the
>> absolute best numerical fidelity when using JSON should always use
>> strings and rely on application logic to ensure that a suitable
>> bignum/bigdecimal implementation exists.
>>
>> HTH,
>> Paul Davis
>
> I mostly agree, though:
>
> sqlite> insert into foo(bar) values(1.0);
> sqlite> select * from foo;
> 1.0
>
Oh, in case I wasn't clear, we should patch ejson so it returns "1.0"
for doubles, not arguing there. I'm just railing against the idea that
we should attempt some hack at storing tagged user data in a weird
attempt to return byte identical representations of data.
>
> Which isn't the case in couchdb and is somehow problematic and
> actually must be solved in 1.2.
>
> Also I would argue that we are here to provide an alternative to this
> real but old world. If we can do better, why not? Also I'm interrested
> to know why we are currently limited. If we really can't find a
> solution that's ok, however if we do it, and time is the only
> constraint maybe it worth a ticket and add on the next release todo ?
>
> - benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis <pa...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 3:09 AM, <ro...@gmail.com> wrote:
>> I've been following this thread with interest and concern.
>>
>> None of you will know me, so let me first say I'm a Couch end user and
>> developer - and a huge fan of the technology who is worried about the
>> future direction of Couch following the Couchbase debacle.
>>
>> Regardless of the subtleties, what the RFC might say, what other systems
>> might do, to me it seems a screaming fundamental that what I put in to the
>> data store is what comes back from it.
>>
>> If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1,
>> 1.0000000000000000000000001 or anything other than exactly the same
>> document that I stored in the first place.
>>
>> Same goes for storing 1
>>
>> I expect to get back 1, not 1.0 or any other mangled version regardless of
>> how arguably mathematically equivalent it might be.
>>
>> So rule 1 has to be, whatever I put in, I get back.
>>
>> What happens at a view level is different. If I've stored 1.0 or 1 as a
>> numeric (ie non-string) value, then what happens in the javascript of a
>> view is more flexible. Here I'm living in the real world of nasty floats
>> etc and in this case my view code should take appropriate care of what the
>> number might actually be. I'd kind of expect anything with a decimal point
>> to be interpreted as a float and anything without one to be interpreted as
>> an integer. That seems pretty basic and easy to understand.
>>
>> Apologies if I'm missing the point - and obviously I'm new around here, but
>> the one inviolable point to me seems to be that whatever I store, I should
>> get back unchanged. Period. If we break that, we're no longer a data store.
>>
>> Roger
>
> Roger,
>
> Welcome!
>
> The issue here is how we define "same". Given your examples you appear
> to be arguing for byte level equivalence between input and output.
> While this may seem quite logical and even perhaps a necessity for
> something that calls itself a datastore, its not how the world works.
> Rather than convince you, I'll just show two examples:
>
> psql (9.0.5, server 9.0.3)
> Type "help" for help.
>
> davisp=# create table foo(bar REAL);
> CREATE TABLE
> davisp=# insert into foo(bar) values(1.00000000000000000001);
> INSERT 0 1
> davisp=# select * from foo;
> bar
> -----
> 1
> (1 row)
>
> SQLite version 3.7.7 2011-06-25 16:35:41
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> create table foo(bar REAL);
> sqlite> insert into foo(bar) values(1.00000000000000000001);
> sqlite> select * from foo;
> 1.0
>
> I'd try MySQL but I bet it returns 2.89 because of some bug.
>
> Anyway, my the point is that datastores do change the representation
> of data inserted into them and will have differences in the output
> returned.
>
> So while some may consider this a screaming fundamental, its really a
> whole lot more complicated.
>
> In the end, as we've constantly repeated, anyone that wants the
> absolute best numerical fidelity when using JSON should always use
> strings and rely on application logic to ensure that a suitable
> bignum/bigdecimal implementation exists.
>
> HTH,
> Paul Davis
I mostly agree, though:
sqlite> insert into foo(bar) values(1.0);
sqlite> select * from foo;
1.0
Which isn't the case in couchdb and is somehow problematic and
actually must be solved in 1.2.
Also I would argue that we are here to provide an alternative to this
real but old world. If we can do better, why not? Also I'm interrested
to know why we are currently limited. If we really can't find a
solution that's ok, however if we do it, and time is the only
constraint maybe it worth a ticket and add on the next release todo ?
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Thanks, commented on the other threads. Lets close this thread for now.
On Tue, Feb 14, 2012 at 12:16 PM, Benoit Chesneau <bc...@gmail.com>wrote:
> On Tue, Feb 14, 2012 at 1:13 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > I am going to halt this thread here, and split it in to two:
> >
> > - Issues blocking the 1.2.0 release
> > - Roadmap for the 1.3.0 release
> >
>
> @rnewson just opened teh 1410 which split the work :)
>
> > Please move anything to do with fixing regressions and release blockers
> to
> > the 1.2.0 thread.
>
> >
> https://issues.apache.org/jira/browse/COUCHDB-1407
>
> > Please move anything to do with what we want to do with number handling
> in
> > to the 1.3.0 thread.
> >
>
> https://issues.apache.org/jira/browse/COUCHDB-1410 :)
> > Thank you.
> >
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Feb 14, 2012 at 1:13 PM, Noah Slater <ns...@tumbolia.org> wrote:
> I am going to halt this thread here, and split it in to two:
>
> - Issues blocking the 1.2.0 release
> - Roadmap for the 1.3.0 release
>
@rnewson just opened teh 1410 which split the work :)
> Please move anything to do with fixing regressions and release blockers to
> the 1.2.0 thread.
>
https://issues.apache.org/jira/browse/COUCHDB-1407
> Please move anything to do with what we want to do with number handling in
> to the 1.3.0 thread.
>
https://issues.apache.org/jira/browse/COUCHDB-1410 :)
> Thank you.
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
I am going to halt this thread here, and split it in to two:
- Issues blocking the 1.2.0 release
- Roadmap for the 1.3.0 release
Please move anything to do with fixing regressions and release blockers to
the 1.2.0 thread.
Please move anything to do with what we want to do with number handling in
to the 1.3.0 thread.
Thank you.
On Tue, Feb 14, 2012 at 8:38 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Tue, Feb 14, 2012 at 5:35 AM, Paul Davis <pa...@gmail.com>
> wrote:
> >> In other words, instead of an experimental encoding trick, CouchDB
> >> used well-known decimal types. Would that change your opinion at all?
> >>
> >
> > Hypothetically I wouldn't reject it out of hand. Hypothetically, if
> > something were to exist and were significantly less intrusive than a
> > tagged binary then maybe.
>
> I would like to define "intrusive." That would more clearly show
> whether this exercise is worthwhile.
>
> > Though I hypothesize that nothing like this
> > exists. Erlang's type system is basic and has no notion of operator
> > overloading or otherwise.
>
> That is a big issue. Even if something exists, I admit it pushes this
> discussion out of scope regarding "what to do about the 1.2 release."
>
> I found https://github.com/tim/erlang-decimal which says it is
> implemented from http://speleotrove.com/decimal/ which seems to be
> created at IBM.
>
> > Thus, at best, we provide mathematical
> > routines for internal use but nothing else changes much. It'd still be
> > some sort of tagged value that we'd have to use function calls to do
> > any sort of mathematical manipulation if the need were to arise.
>
> Couch rarely manipulates these numbers. It's basically parsing JSON so
> it can update a _rev key
>
> Couch processes numbers from JSON when a map function emits a number
> in the key. It sends JSON to couch over stdio, and couch has to put it
> in the index. So--hypothetically--Couch should either (a) parse to
> float instead, or (b) have greater/less-than support, with no speed
> regression. (I think I recall that the collation functions are
> straightforward, pattern matching could trigger this alternate
> comparison function.)
>
> Am I missing any other situations where couch must both parse a number
> to process it and also to re-encode it?
>
> > Also note that while JavaScript might be a PITA, its not the only view
> > server and other view servers (specifically Erlang) will have to deal
> > with this.
>
> I'm not sure what you're getting at. The whole point is to make The
> Perfect JSON Encoder. So if I store {"one":1, "one.point.oh":1.0} then
> the line printed on stdio to the view server would contain {"one":1,
> "one.point.oh"1.0} and Javascript/JSON2/whatever is free to parse that
> however it likes.
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Feb 14, 2012 at 5:35 AM, Paul Davis <pa...@gmail.com> wrote:
>> In other words, instead of an experimental encoding trick, CouchDB
>> used well-known decimal types. Would that change your opinion at all?
>>
>
> Hypothetically I wouldn't reject it out of hand. Hypothetically, if
> something were to exist and were significantly less intrusive than a
> tagged binary then maybe.
I would like to define "intrusive." That would more clearly show
whether this exercise is worthwhile.
> Though I hypothesize that nothing like this
> exists. Erlang's type system is basic and has no notion of operator
> overloading or otherwise.
That is a big issue. Even if something exists, I admit it pushes this
discussion out of scope regarding "what to do about the 1.2 release."
I found https://github.com/tim/erlang-decimal which says it is
implemented from http://speleotrove.com/decimal/ which seems to be
created at IBM.
> Thus, at best, we provide mathematical
> routines for internal use but nothing else changes much. It'd still be
> some sort of tagged value that we'd have to use function calls to do
> any sort of mathematical manipulation if the need were to arise.
Couch rarely manipulates these numbers. It's basically parsing JSON so
it can update a _rev key
Couch processes numbers from JSON when a map function emits a number
in the key. It sends JSON to couch over stdio, and couch has to put it
in the index. So--hypothetically--Couch should either (a) parse to
float instead, or (b) have greater/less-than support, with no speed
regression. (I think I recall that the collation functions are
straightforward, pattern matching could trigger this alternate
comparison function.)
Am I missing any other situations where couch must both parse a number
to process it and also to re-encode it?
> Also note that while JavaScript might be a PITA, its not the only view
> server and other view servers (specifically Erlang) will have to deal
> with this.
I'm not sure what you're getting at. The whole point is to make The
Perfect JSON Encoder. So if I store {"one":1, "one.point.oh":1.0} then
the line printed on stdio to the view server would contain {"one":1,
"one.point.oh"1.0} and Javascript/JSON2/whatever is free to parse that
however it likes.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Feb 14, 2012 at 12:12 PM, Robert Newson <rn...@apache.org> wrote:
> The first time I encountered CouchDB's (or, strictly, SpiderMonkey's)
> rather deficient number handling was quite sobering. I hear Paul's
> concern that JSON doesn't define anything useful for numbers at all
> (I'd argue that its specification is actually worse than useless). For
> 1.2.0, I'd be +1 on removing the obvious regression that %g
> introduced.
+1
> For 1.3.0, I'd love to see some formalization of how
> CouchDB handles numbers (with an explicit promise to remain compatible
> in future releases). I'd prefer a transparently lossless approach but
> the edge cases might be too much to handle. After all, erlang
> automatically handles big integers if you overflow but is also
> silently converts integers to decimals if you're not careful.
>
> Shorter Version: CouchDB should have first-class support for numerical
> data, over and above the JSON spec.
>
+1
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Robert Newson <rn...@apache.org>.
including bigdecimal.js in the next release would be very handy (and
fulfils one of my earliest tickets, COUCHDB-796).
Sorry for dropping out of the thread for a while there, having
connectivity issues at home. I'm now perched halfway up a mountain
holding a hand-crafted aerial towards the heavens; seems to be
working.
The first time I encountered CouchDB's (or, strictly, SpiderMonkey's)
rather deficient number handling was quite sobering. I hear Paul's
concern that JSON doesn't define anything useful for numbers at all
(I'd argue that its specification is actually worse than useless). For
1.2.0, I'd be +1 on removing the obvious regression that %g
introduced. For 1.3.0, I'd love to see some formalization of how
CouchDB handles numbers (with an explicit promise to remain compatible
in future releases). I'd prefer a transparently lossless approach but
the edge cases might be too much to handle. After all, erlang
automatically handles big integers if you overflow but is also
silently converts integers to decimals if you're not careful.
Shorter Version: CouchDB should have first-class support for numerical
data, over and above the JSON spec.
B.
On 14 February 2012 05:35, Paul Davis <pa...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 7:23 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <pa...@gmail.com> wrote:
>>> The issue here is how we define "same". Given your examples you appear
>>> to be arguing for byte level equivalence between input and output.
>>> While this may seem quite logical and even perhaps a necessity for
>>> something that calls itself a datastore, its not how the world works.
>>> Rather than convince you, I'll just show two examples:
>>
>> Hi, Paul. I hope you'll agree that just because SQL does that, CouchDB
>> doesn't necessarily have to. Of course, you make a strong case that
>> Couch can do what most people expect (round trip the sequence of
>> numerals through IEEE floats).
>>
>
> I like this description and I agree completely. I only meant to
> illustrate that numbers pass through IEEE representations often enough
> that its not very safe to assume that numeric representations won't
> change.
>
>> FWIW, I started out by taking a similar position as yours; however, I
>> feel the users and Filipe are describing a more relaxing Couch.
>>
>
> I disagree heartily. Expecting every bit of internal code to remember
> that some JSON may or may not be partially parsed is about as
> unrelaxing as possible. Saying that JSON numbers that contain a
> decimal point or exponent are represented internally as IEEE-754
> double precision floating points is much more relaxing.
>
>> I notice you didn't like Filipe's patch; but what if CouchDB used a
>> hypothetical decimal implementation? It had honest-to-God proper
>> numbers, with round-trip identity and all of it? (View collation is a
>> distraction since that is Javascript and we can all expect IEEE-754.)
>>
>> In other words, instead of an experimental encoding trick, CouchDB
>> used well-known decimal types. Would that change your opinion at all?
>>
>
> Hypothetically I wouldn't reject it out of hand. Hypothetically, if
> something were to exist and were significantly less intrusive than a
> tagged binary then maybe. Though I hypothesize that nothing like this
> exists. Erlang's type system is basic and has no notion of operator
> overloading or otherwise. Thus, at best, we provide mathematical
> routines for internal use but nothing else changes much. It'd still be
> some sort of tagged value that we'd have to use function calls to do
> any sort of mathematical manipulation if the need were to arise.
>
> Also note that while JavaScript might be a PITA, its not the only view
> server and other view servers (specifically Erlang) will have to deal
> with this.
>
>>> I'd try MySQL but I bet it returns 2.89 because of some bug.
>>
>> Hey, come on, that's bigotry.
>>
>
> http://sql-info.de/mysql/gotchas.html#1_14
>
>>> In the end, as we've constantly repeated, anyone that wants the
>>> absolute best numerical fidelity when using JSON should always use
>>> strings and rely on application logic to ensure that a suitable
>>> bignum/bigdecimal implementation exists.
>>
>> CouchDB has one already, https://github.com/iriscouch/bigdecimal.js
>>
>> I used GWT to compile the Apache Harmony (Java) BigDecimal
>> implementation to Javascript, and wrap it in CommonJS. It works in
>> CouchDB, Node.js, and browsers.
>>
>
> This approach is relaxing. If users need special number handling then
> they can use special number handling.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 13, 2012 at 7:23 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <pa...@gmail.com> wrote:
>> The issue here is how we define "same". Given your examples you appear
>> to be arguing for byte level equivalence between input and output.
>> While this may seem quite logical and even perhaps a necessity for
>> something that calls itself a datastore, its not how the world works.
>> Rather than convince you, I'll just show two examples:
>
> Hi, Paul. I hope you'll agree that just because SQL does that, CouchDB
> doesn't necessarily have to. Of course, you make a strong case that
> Couch can do what most people expect (round trip the sequence of
> numerals through IEEE floats).
>
I like this description and I agree completely. I only meant to
illustrate that numbers pass through IEEE representations often enough
that its not very safe to assume that numeric representations won't
change.
> FWIW, I started out by taking a similar position as yours; however, I
> feel the users and Filipe are describing a more relaxing Couch.
>
I disagree heartily. Expecting every bit of internal code to remember
that some JSON may or may not be partially parsed is about as
unrelaxing as possible. Saying that JSON numbers that contain a
decimal point or exponent are represented internally as IEEE-754
double precision floating points is much more relaxing.
> I notice you didn't like Filipe's patch; but what if CouchDB used a
> hypothetical decimal implementation? It had honest-to-God proper
> numbers, with round-trip identity and all of it? (View collation is a
> distraction since that is Javascript and we can all expect IEEE-754.)
>
> In other words, instead of an experimental encoding trick, CouchDB
> used well-known decimal types. Would that change your opinion at all?
>
Hypothetically I wouldn't reject it out of hand. Hypothetically, if
something were to exist and were significantly less intrusive than a
tagged binary then maybe. Though I hypothesize that nothing like this
exists. Erlang's type system is basic and has no notion of operator
overloading or otherwise. Thus, at best, we provide mathematical
routines for internal use but nothing else changes much. It'd still be
some sort of tagged value that we'd have to use function calls to do
any sort of mathematical manipulation if the need were to arise.
Also note that while JavaScript might be a PITA, its not the only view
server and other view servers (specifically Erlang) will have to deal
with this.
>> I'd try MySQL but I bet it returns 2.89 because of some bug.
>
> Hey, come on, that's bigotry.
>
http://sql-info.de/mysql/gotchas.html#1_14
>> In the end, as we've constantly repeated, anyone that wants the
>> absolute best numerical fidelity when using JSON should always use
>> strings and rely on application logic to ensure that a suitable
>> bignum/bigdecimal implementation exists.
>
> CouchDB has one already, https://github.com/iriscouch/bigdecimal.js
>
> I used GWT to compile the Apache Harmony (Java) BigDecimal
> implementation to Javascript, and wrap it in CommonJS. It works in
> CouchDB, Node.js, and browsers.
>
This approach is relaxing. If users need special number handling then
they can use special number handling.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <pa...@gmail.com> wrote:
> The issue here is how we define "same". Given your examples you appear
> to be arguing for byte level equivalence between input and output.
> While this may seem quite logical and even perhaps a necessity for
> something that calls itself a datastore, its not how the world works.
> Rather than convince you, I'll just show two examples:
Hi, Paul. I hope you'll agree that just because SQL does that, CouchDB
doesn't necessarily have to. Of course, you make a strong case that
Couch can do what most people expect (round trip the sequence of
numerals through IEEE floats).
FWIW, I started out by taking a similar position as yours; however, I
feel the users and Filipe are describing a more relaxing Couch.
I notice you didn't like Filipe's patch; but what if CouchDB used a
hypothetical decimal implementation? It had honest-to-God proper
numbers, with round-trip identity and all of it? (View collation is a
distraction since that is Javascript and we can all expect IEEE-754.)
In other words, instead of an experimental encoding trick, CouchDB
used well-known decimal types. Would that change your opinion at all?
> I'd try MySQL but I bet it returns 2.89 because of some bug.
Hey, come on, that's bigotry.
> In the end, as we've constantly repeated, anyone that wants the
> absolute best numerical fidelity when using JSON should always use
> strings and rely on application logic to ensure that a suitable
> bignum/bigdecimal implementation exists.
CouchDB has one already, https://github.com/iriscouch/bigdecimal.js
I used GWT to compile the Apache Harmony (Java) BigDecimal
implementation to Javascript, and wrap it in CommonJS. It works in
CouchDB, Node.js, and browsers.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Feb 13, 2012 at 3:09 AM, <ro...@gmail.com> wrote:
> I've been following this thread with interest and concern.
>
> None of you will know me, so let me first say I'm a Couch end user and
> developer - and a huge fan of the technology who is worried about the
> future direction of Couch following the Couchbase debacle.
>
> Regardless of the subtleties, what the RFC might say, what other systems
> might do, to me it seems a screaming fundamental that what I put in to the
> data store is what comes back from it.
>
> If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1,
> 1.0000000000000000000000001 or anything other than exactly the same
> document that I stored in the first place.
>
> Same goes for storing 1
>
> I expect to get back 1, not 1.0 or any other mangled version regardless of
> how arguably mathematically equivalent it might be.
>
> So rule 1 has to be, whatever I put in, I get back.
>
> What happens at a view level is different. If I've stored 1.0 or 1 as a
> numeric (ie non-string) value, then what happens in the javascript of a
> view is more flexible. Here I'm living in the real world of nasty floats
> etc and in this case my view code should take appropriate care of what the
> number might actually be. I'd kind of expect anything with a decimal point
> to be interpreted as a float and anything without one to be interpreted as
> an integer. That seems pretty basic and easy to understand.
>
> Apologies if I'm missing the point - and obviously I'm new around here, but
> the one inviolable point to me seems to be that whatever I store, I should
> get back unchanged. Period. If we break that, we're no longer a data store.
>
> Roger
Roger,
Welcome!
The issue here is how we define "same". Given your examples you appear
to be arguing for byte level equivalence between input and output.
While this may seem quite logical and even perhaps a necessity for
something that calls itself a datastore, its not how the world works.
Rather than convince you, I'll just show two examples:
psql (9.0.5, server 9.0.3)
Type "help" for help.
davisp=# create table foo(bar REAL);
CREATE TABLE
davisp=# insert into foo(bar) values(1.00000000000000000001);
INSERT 0 1
davisp=# select * from foo;
bar
-----
1
(1 row)
SQLite version 3.7.7 2011-06-25 16:35:41
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table foo(bar REAL);
sqlite> insert into foo(bar) values(1.00000000000000000001);
sqlite> select * from foo;
1.0
I'd try MySQL but I bet it returns 2.89 because of some bug.
Anyway, my the point is that datastores do change the representation
of data inserted into them and will have differences in the output
returned.
So while some may consider this a screaming fundamental, its really a
whole lot more complicated.
In the end, as we've constantly repeated, anyone that wants the
absolute best numerical fidelity when using JSON should always use
strings and rely on application logic to ensure that a suitable
bignum/bigdecimal implementation exists.
HTH,
Paul Davis
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Filipe David Manana <fd...@apache.org>.
On Mon, Feb 13, 2012 at 4:04 PM, Jeroen Janssen
<je...@gmail.com> wrote:
> Hi,
>
> Just a quick check (since I am not entirely familiar with this).
> Does this also imply that the couchdb 'on disk' format needs a version increase?
> (since the term representing numeric fields changes?)
I don't think it's needed.
The biggest issue here I see at the moment is view collation, as for
it to work properly it would imply to actually decode numbers that are
part of keys emitted by the map functions in order for proper view
collation to happen.
>
> Best regards,
>
> Jeroen Janssen
>
> On Mon, Feb 13, 2012 at 4:46 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>> On Mon, Feb 13, 2012 at 10:55 AM, Randall Leeds <ra...@gmail.com> wrote:
>>>
>>> A very rigorous approach might be to work with the tokenized, but not
>>> decoded, JSON so that numeric field values could be passed verbatim. For
>>> 1.2 I'd just like to see the integer regression patched.
>>
>> Catching up on this thread, that seems to be what I had in mind as well.
>> The following simple patch would do it:
>>
>> http://friendpaste.com/1H4zOcciVjajGuYTRyrUUB
>>
>> For every JSON document coming from the http interface, it doesn't
>> decode numbers, only validates them, and have them represented by the
>> term {json, RawJsonNumberIoList} (this term is something already used
>> by mochijson2, but not by ejson before).
>>
>> For JSON coming from the view server, like the 1 coming from a
>> validate_doc_update request, we would keep doing as we do now, except
>> for map/reduce values where we would use the approach mentioned above.
>>
>> The above patch is just a quick experiment, I didn't attempt to verify
>> all possible scenarios. Only verified that the test suite passes.
>>
>> With the patch:
>>
>> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
>> "integer": 1, "float": 1.0}'
>> {"ok":true,"id":"doc1","rev":"1-67bc2600ba5ce41db1961e410f79a611"}
>>
>> $ curl http://localhost:5984/test/doc1
>> {"_id":"doc1","_rev":"1-67bc2600ba5ce41db1961e410f79a611","integer":1,"float":1.0}
>>
>> Without (current behaviour):
>>
>> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
>> "integer": 1, "float": 1.0}'
>> {"ok":true,"id":"doc1","rev":"1-308b01bbabea74f0cea2af7d0e270fb8"}
>>
>> $ curl http://localhost:5984/test/doc1
>> {"_id":"doc1","_rev":"1-308b01bbabea74f0cea2af7d0e270fb8","integer":1,"float":1}
>>
>>
>>
>> --
>> Filipe David Manana,
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
--
Filipe David Manana,
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jeroen Janssen <je...@gmail.com>.
Hi,
Just a quick check (since I am not entirely familiar with this).
Does this also imply that the couchdb 'on disk' format needs a version increase?
(since the term representing numeric fields changes?)
Best regards,
Jeroen Janssen
On Mon, Feb 13, 2012 at 4:46 PM, Filipe David Manana
<fd...@apache.org> wrote:
> On Mon, Feb 13, 2012 at 10:55 AM, Randall Leeds <ra...@gmail.com> wrote:
>>
>> A very rigorous approach might be to work with the tokenized, but not
>> decoded, JSON so that numeric field values could be passed verbatim. For
>> 1.2 I'd just like to see the integer regression patched.
>
> Catching up on this thread, that seems to be what I had in mind as well.
> The following simple patch would do it:
>
> http://friendpaste.com/1H4zOcciVjajGuYTRyrUUB
>
> For every JSON document coming from the http interface, it doesn't
> decode numbers, only validates them, and have them represented by the
> term {json, RawJsonNumberIoList} (this term is something already used
> by mochijson2, but not by ejson before).
>
> For JSON coming from the view server, like the 1 coming from a
> validate_doc_update request, we would keep doing as we do now, except
> for map/reduce values where we would use the approach mentioned above.
>
> The above patch is just a quick experiment, I didn't attempt to verify
> all possible scenarios. Only verified that the test suite passes.
>
> With the patch:
>
> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
> "integer": 1, "float": 1.0}'
> {"ok":true,"id":"doc1","rev":"1-67bc2600ba5ce41db1961e410f79a611"}
>
> $ curl http://localhost:5984/test/doc1
> {"_id":"doc1","_rev":"1-67bc2600ba5ce41db1961e410f79a611","integer":1,"float":1.0}
>
> Without (current behaviour):
>
> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
> "integer": 1, "float": 1.0}'
> {"ok":true,"id":"doc1","rev":"1-308b01bbabea74f0cea2af7d0e270fb8"}
>
> $ curl http://localhost:5984/test/doc1
> {"_id":"doc1","_rev":"1-308b01bbabea74f0cea2af7d0e270fb8","integer":1,"float":1}
>
>
>
> --
> Filipe David Manana,
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Paul Davis <pa...@gmail.com>.
I'm really not a fan of this. Rather than simplify the situation it's
adding a whole big set of questions on what format we have in a large
number of API end points. Seems like we should just worry about
documenting how our JSON decoder/encoder works and leave it at that.
Last night while chatting with Brian Mitchell I hit on the idea of
having a compliance test suite for JSON round tripping. There are a
large number of weird edge cases in JSON that most people never think
about. Having some sort of automatically generated table of behaviors
for lots of deserialize/serialize round trips seems like it could
solve most of the issues at hand.
On Mon, Feb 13, 2012 at 9:46 AM, Filipe David Manana
<fd...@apache.org> wrote:
> On Mon, Feb 13, 2012 at 10:55 AM, Randall Leeds <ra...@gmail.com> wrote:
>>
>> A very rigorous approach might be to work with the tokenized, but not
>> decoded, JSON so that numeric field values could be passed verbatim. For
>> 1.2 I'd just like to see the integer regression patched.
>
> Catching up on this thread, that seems to be what I had in mind as well.
> The following simple patch would do it:
>
> http://friendpaste.com/1H4zOcciVjajGuYTRyrUUB
>
> For every JSON document coming from the http interface, it doesn't
> decode numbers, only validates them, and have them represented by the
> term {json, RawJsonNumberIoList} (this term is something already used
> by mochijson2, but not by ejson before).
>
> For JSON coming from the view server, like the 1 coming from a
> validate_doc_update request, we would keep doing as we do now, except
> for map/reduce values where we would use the approach mentioned above.
>
> The above patch is just a quick experiment, I didn't attempt to verify
> all possible scenarios. Only verified that the test suite passes.
>
> With the patch:
>
> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
> "integer": 1, "float": 1.0}'
> {"ok":true,"id":"doc1","rev":"1-67bc2600ba5ce41db1961e410f79a611"}
>
> $ curl http://localhost:5984/test/doc1
> {"_id":"doc1","_rev":"1-67bc2600ba5ce41db1961e410f79a611","integer":1,"float":1.0}
>
> Without (current behaviour):
>
> $ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
> "integer": 1, "float": 1.0}'
> {"ok":true,"id":"doc1","rev":"1-308b01bbabea74f0cea2af7d0e270fb8"}
>
> $ curl http://localhost:5984/test/doc1
> {"_id":"doc1","_rev":"1-308b01bbabea74f0cea2af7d0e270fb8","integer":1,"float":1}
>
>
>
> --
> Filipe David Manana,
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Filipe David Manana <fd...@apache.org>.
On Mon, Feb 13, 2012 at 10:55 AM, Randall Leeds <ra...@gmail.com> wrote:
>
> A very rigorous approach might be to work with the tokenized, but not
> decoded, JSON so that numeric field values could be passed verbatim. For
> 1.2 I'd just like to see the integer regression patched.
Catching up on this thread, that seems to be what I had in mind as well.
The following simple patch would do it:
http://friendpaste.com/1H4zOcciVjajGuYTRyrUUB
For every JSON document coming from the http interface, it doesn't
decode numbers, only validates them, and have them represented by the
term {json, RawJsonNumberIoList} (this term is something already used
by mochijson2, but not by ejson before).
For JSON coming from the view server, like the 1 coming from a
validate_doc_update request, we would keep doing as we do now, except
for map/reduce values where we would use the approach mentioned above.
The above patch is just a quick experiment, I didn't attempt to verify
all possible scenarios. Only verified that the test suite passes.
With the patch:
$ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
"integer": 1, "float": 1.0}'
{"ok":true,"id":"doc1","rev":"1-67bc2600ba5ce41db1961e410f79a611"}
$ curl http://localhost:5984/test/doc1
{"_id":"doc1","_rev":"1-67bc2600ba5ce41db1961e410f79a611","integer":1,"float":1.0}
Without (current behaviour):
$ curl -X PUT http://localhost:5984/test/doc1 -d '{"_id": "doc1",
"integer": 1, "float": 1.0}'
{"ok":true,"id":"doc1","rev":"1-308b01bbabea74f0cea2af7d0e270fb8"}
$ curl http://localhost:5984/test/doc1
{"_id":"doc1","_rev":"1-308b01bbabea74f0cea2af7d0e270fb8","integer":1,"float":1}
--
Filipe David Manana,
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Randall Leeds <ra...@gmail.com>.
On Feb 13, 2012 1:10 AM, <roger.moffatt
<ro...@gmail.com>
gmail.com <ro...@gmail.com>> wrote:
>
> So rule 1 has to be, whatever I put in, I get back.
>
> What happens at a view level is different. If I've stored 1.0 or 1 as a
> numeric (ie non-string) value, then what happens in the javascript of a
> view is more flexible. Here I'm living in the real world of nasty floats
> etc and in this case my view code should take appropriate care of what the
> number might actually be. I'd kind of expect anything with a decimal point
> to be interpreted as a float and anything without one to be interpreted as
> an integer. That seems pretty basic and easy to understand.
Thanks, Roger. You seem to be touching on is the fact that CouchDB puts
incoming JSON through a round trip always, and Paul that floats always
incur lossy transformations. Since we can't fix encoding/decoding in
general (though we can for integers), we'd like not to touch the JSON that
hits disk so that it's always stored verbatim, but API responses need to
insert metadata for many requests. I recall that Paul objected to the
string manipulation that would be required to join the disk JSON with the
meta properties.
A very rigorous approach might be to work with the tokenized, but not
decoded, JSON so that numeric field values could be passed verbatim. For
1.2 I'd just like to see the integer regression patched.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Roger,
On Feb 13, 2012, at 10:09 , roger.moffatt@gmail.com wrote:
> I've been following this thread with interest and concern.
>
> None of you will know me, so let me first say I'm a Couch end user and
> developer - and a huge fan of the technology who is worried about the
> future direction of Couch following the Couchbase debacle.
Not to branch off too far, but what debacle other than "Damien left the
ship"? I’m happy to discuss anything that is unclear.
> Regardless of the subtleties, what the RFC might say, what other systems
> might do, to me it seems a screaming fundamental that what I put in to the
> data store is what comes back from it.
>
> If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1,
> 1.0000000000000000000000001 or anything other than exactly the same
> document that I stored in the first place.
>
> Same goes for storing 1
>
> I expect to get back 1, not 1.0 or any other mangled version regardless of
> how arguably mathematically equivalent it might be.
>
> So rule 1 has to be, whatever I put in, I get back.
>
> What happens at a view level is different. If I've stored 1.0 or 1 as a
> numeric (ie non-string) value, then what happens in the javascript of a
> view is more flexible. Here I'm living in the real world of nasty floats
> etc and in this case my view code should take appropriate care of what the
> number might actually be. I'd kind of expect anything with a decimal point
> to be interpreted as a float and anything without one to be interpreted as
> an integer. That seems pretty basic and easy to understand.
>
> Apologies if I'm missing the point - and obviously I'm new around here, but
> the one inviolable point to me seems to be that whatever I store, I should
> get back unchanged. Period. If we break that, we're no longer a data store.
Thanks for writing in. I don't want to side pro or against your point, but
just thank you for taking the time (and courage I presume) to write in and
weigh in with your opinion. CouchDB is better off because of it and I hope
this encourages others to follow you :)
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by ro...@gmail.com.
I've been following this thread with interest and concern.
None of you will know me, so let me first say I'm a Couch end user and
developer - and a huge fan of the technology who is worried about the
future direction of Couch following the Couchbase debacle.
Regardless of the subtleties, what the RFC might say, what other systems
might do, to me it seems a screaming fundamental that what I put in to the
data store is what comes back from it.
If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1,
1.0000000000000000000000001 or anything other than exactly the same
document that I stored in the first place.
Same goes for storing 1
I expect to get back 1, not 1.0 or any other mangled version regardless of
how arguably mathematically equivalent it might be.
So rule 1 has to be, whatever I put in, I get back.
What happens at a view level is different. If I've stored 1.0 or 1 as a
numeric (ie non-string) value, then what happens in the javascript of a
view is more flexible. Here I'm living in the real world of nasty floats
etc and in this case my view code should take appropriate care of what the
number might actually be. I'd kind of expect anything with a decimal point
to be interpreted as a float and anything without one to be interpreted as
an integer. That seems pretty basic and easy to understand.
Apologies if I'm missing the point - and obviously I'm new around here, but
the one inviolable point to me seems to be that whatever I store, I should
get back unchanged. Period. If we break that, we're no longer a data store.
Roger
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
Hi, Paul. Thank you very much for this!
IMHO, in future, Couch might use a BigDecimal type when working with
documents' numbers. It never *computes* anything with those numbers,
so performance should be okay; it's just to preserve the user's data
through a decode/encode round-trip.
For now, you make a persuasive point about the practical matter (not
that you require my approval!)
My earlier tangent was to argue that Couch should be allowed to trim
leading or trailing digits if it doesn't change the "real" value, for
which I dragged a comic book into the discussion. Sorry for that.
Dirkjan and Benoit changed my mind.
On Mon, Feb 13, 2012 at 6:55 AM, Paul Davis <pa...@gmail.com> wrote:
> So yeah. Numbers are hard.
>
> Firstly, anyone that mentioned RFC 4627 or JavaScript behavior is
> walking down a path entirely orthogonal to the issue at hand. Jason
> almost had it when he talked about them being different but then he
> went off on some weird tangent and lost me.
>
> In a nutshell, the issue is this:
>
> CPU's work with bits. Humans (and JSON sorta) work with numbers as a
> string of numerals with some punctuation. This is a lossy conversion.
>
> So, back to the details.
>
> COUCHDB-1407 reports that ejson now encodes the value "1.0" as "1".
> While we can wax philosophically about this, the bottom line is that
> this breaks a level of equality. Specifically:
>
> 1> ejson:decode(ejson:encode(1.0)) =:= 1.0.
> false
>
> This is precisely because the %g formatting used underneath removes
> trailing zeros and decimal points.
>
> On the face of it, this is bad. And I agree. There's a simple enough
> fix (and its not what Bob Newson suggested, but I'm going to leave him
> hanging for a bit).
>
> But, before we get all crazy, we should contemplate a few other fun cases:
>
> 1. Both mochijson2 and ejson change some number representations
>
> 5> mochijson2:encode(mochijson2:decode("1E1")) =:= "1E1".
> false
> 6> ejson:encode(ejson:decode("1E1")) =:= "1E1".
> false
>
> 2. Both mochijson2 and ejson turn numbers with exponents into IEEE-754
> internally
>
> 7> ejson:decode("1E1") =:= 10.
> false
> 8> mochijson2:decode("1E1") =:= 10.
> false
>
> 3. Others but I'm tired from staring at math.
>
> Basically, the end result is that we can match mochijson2's decoder
> damn near identically (At least, I know of no known differences in
> decoding in Jiffy). But now we get to the hard part.
>
> Mochijson2 does some fancy ass magic for encoding IEEE-754 values. And
> when I say fancy, I mean, implements an algorithm published in some
> random paper from 1996 based on the paper's author's Scheme
> implementation. I spent about twelve hours today trying to duplicate
> before I realized that it depends on having an integral type that can
> represent values with more than 64 bits (which made me sad).
>
> EIther way, this is dark voodoo. Anyone that's interested can checkout
> mochinum:digits/1 and the supporting functions for some mind bending
> looks into IEEE-754 representations.
>
> Anyway, bottom line is that 1.0 should be encoded as "1.0". The fix is
> simply to just check for a decimal point and append one if its not
> there. This is what Yajl does and Python appears to behave similarly.
> The patch for Jiffy is at [1] and shows the general idea.
>
> Also, for those still holding on to why %f is not a valid fix, the
> reason is the same as why %g is wrong (and why it needs to be %0.20g.
> printf and friends by default will round to the sixth decimal places.
> So, 0.123456789 would get encoded as "0.123457" which loses precision.
>
> Also, with that patch for Jiffy we never lose precision but the
> eyesore is that we encoded 0.1 as "0.10000000000888" (Roughly). Some
> people find that offensive but I don't really care enough to learn
> arbitrary precision math routines so people can have slightly prettier
> JSON. And I say that after having spent all day trying to make it
> work.
>
> So, yeah. Fix is simple enough.
>
> Also, food for thought: A JSON parser/serializer pair that converts
> all numbers to 42 is technically compliant with the JSON spec.
>
> [1] https://github.com/davisp/jiffy/commit/5042cc946008ee413cc66b9b0addcf33ecd2fd93
>
> On Sat, Feb 11, 2012 at 8:32 AM, Robert Newson <rn...@apache.org> wrote:
>> I'd like some opinions on whether COUCHDB-1407 constitutes a release
>> blocking issue. Yes, I understand that the JSON spec is very weak on
>> numbers, blah blah boo splat. Is this because of the switch to ejson?
>> Is jiffy more compatible on this score?
>>
>> For my part, I'm close to considering it a release-blocking
>> regression. At the very least this change should be included at
>> http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
>> but I'd rather it was fixed.
>>
>> B.
>>
>> On 11 February 2012 10:44, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Sat, Feb 11, 2012 at 4:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
>>>>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>>>>>
>>>>>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>>>>>> > and I asked around. If memory serves, Randall happened to be on at the
>>>>>> > time and he asked me the same question you just did. I said I never
>>>>>> > saw an RFC email and that's when he realized it was not done publicly.
>>>>>>
>>>>>> I was aware the entire time, but I think the motivation is sound and
>>>>>> it needed to be done. A couple committers spoke up to say we didn't
>>>>>> think it was sensitive enough to warrant the private discussion but
>>>>>> ultimately there was broad consensus on the implementation and the
>>>>>> change itself. One of those (let us all celebrate) extremely rare
>>>>>> times where there wasn't opportunity for broad community input.
>>>>>>
>>>>>> Creating a view on _users that pulls the relevant parts of a user
>>>>>> document out is the way forward for public profiles, I think.
>>>>>> If someone would write a blog post showing how that works it'd be
>>>>>> great. In retrospect this would have been a great thing to do weeks
>>>>>> ago. Lesson learned.
>>>>>
>>>>> Just to be clear I don't want to dismiss your concerns. If you believe this
>>>>> needs a config option rather than just documentation now is a good time to
>>>>> speak up loudly since the vote was aborted.
>>>>
>>>> Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
>>>>
>>>> I tested your suggestion, however I do not think it is possible.
>>>> Non-admins cannot access a view.
>>>>
>>>> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
>>>> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
>>>> {"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>>>>
>>>> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
>>>> HTTP/1.1 403 Forbidden
>>>> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
>>>> Date: Sat, 11 Feb 2012 02:57:43 GMT
>>>> Content-Type: text/plain; charset=utf-8
>>>> Content-Length: 102
>>>> Cache-Control: must-revalidate
>>>>
>>>> {"error":"forbidden","reason":"Only admins can access design document
>>>> actions for system databases."}
>>>>
>>> Yes that's by design.
>>>
>>> - benoît
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jan Lehnardt <ja...@apache.org>.
Excellent analysis Paul.
I'd say we go with the patch for 1.2.0 and beyond.
Cheers
Jan
--
On Feb 13, 2012, at 07:55 , Paul Davis wrote:
> So yeah. Numbers are hard.
>
> Firstly, anyone that mentioned RFC 4627 or JavaScript behavior is
> walking down a path entirely orthogonal to the issue at hand. Jason
> almost had it when he talked about them being different but then he
> went off on some weird tangent and lost me.
>
> In a nutshell, the issue is this:
>
> CPU's work with bits. Humans (and JSON sorta) work with numbers as a
> string of numerals with some punctuation. This is a lossy conversion.
>
> So, back to the details.
>
> COUCHDB-1407 reports that ejson now encodes the value "1.0" as "1".
> While we can wax philosophically about this, the bottom line is that
> this breaks a level of equality. Specifically:
>
> 1> ejson:decode(ejson:encode(1.0)) =:= 1.0.
> false
>
> This is precisely because the %g formatting used underneath removes
> trailing zeros and decimal points.
>
> On the face of it, this is bad. And I agree. There's a simple enough
> fix (and its not what Bob Newson suggested, but I'm going to leave him
> hanging for a bit).
>
> But, before we get all crazy, we should contemplate a few other fun cases:
>
> 1. Both mochijson2 and ejson change some number representations
>
> 5> mochijson2:encode(mochijson2:decode("1E1")) =:= "1E1".
> false
> 6> ejson:encode(ejson:decode("1E1")) =:= "1E1".
> false
>
> 2. Both mochijson2 and ejson turn numbers with exponents into IEEE-754
> internally
>
> 7> ejson:decode("1E1") =:= 10.
> false
> 8> mochijson2:decode("1E1") =:= 10.
> false
>
> 3. Others but I'm tired from staring at math.
>
> Basically, the end result is that we can match mochijson2's decoder
> damn near identically (At least, I know of no known differences in
> decoding in Jiffy). But now we get to the hard part.
>
> Mochijson2 does some fancy ass magic for encoding IEEE-754 values. And
> when I say fancy, I mean, implements an algorithm published in some
> random paper from 1996 based on the paper's author's Scheme
> implementation. I spent about twelve hours today trying to duplicate
> before I realized that it depends on having an integral type that can
> represent values with more than 64 bits (which made me sad).
>
> EIther way, this is dark voodoo. Anyone that's interested can checkout
> mochinum:digits/1 and the supporting functions for some mind bending
> looks into IEEE-754 representations.
>
> Anyway, bottom line is that 1.0 should be encoded as "1.0". The fix is
> simply to just check for a decimal point and append one if its not
> there. This is what Yajl does and Python appears to behave similarly.
> The patch for Jiffy is at [1] and shows the general idea.
>
> Also, for those still holding on to why %f is not a valid fix, the
> reason is the same as why %g is wrong (and why it needs to be %0.20g.
> printf and friends by default will round to the sixth decimal places.
> So, 0.123456789 would get encoded as "0.123457" which loses precision.
>
> Also, with that patch for Jiffy we never lose precision but the
> eyesore is that we encoded 0.1 as "0.10000000000888" (Roughly). Some
> people find that offensive but I don't really care enough to learn
> arbitrary precision math routines so people can have slightly prettier
> JSON. And I say that after having spent all day trying to make it
> work.
>
> So, yeah. Fix is simple enough.
>
> Also, food for thought: A JSON parser/serializer pair that converts
> all numbers to 42 is technically compliant with the JSON spec.
>
> [1] https://github.com/davisp/jiffy/commit/5042cc946008ee413cc66b9b0addcf33ecd2fd93
>
> On Sat, Feb 11, 2012 at 8:32 AM, Robert Newson <rn...@apache.org> wrote:
>> I'd like some opinions on whether COUCHDB-1407 constitutes a release
>> blocking issue. Yes, I understand that the JSON spec is very weak on
>> numbers, blah blah boo splat. Is this because of the switch to ejson?
>> Is jiffy more compatible on this score?
>>
>> For my part, I'm close to considering it a release-blocking
>> regression. At the very least this change should be included at
>> http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
>> but I'd rather it was fixed.
>>
>> B.
>>
>> On 11 February 2012 10:44, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Sat, Feb 11, 2012 at 4:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
>>>>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>>>>>
>>>>>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>>>>>>> Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>>>>>>> and I asked around. If memory serves, Randall happened to be on at the
>>>>>>> time and he asked me the same question you just did. I said I never
>>>>>>> saw an RFC email and that's when he realized it was not done publicly.
>>>>>>
>>>>>> I was aware the entire time, but I think the motivation is sound and
>>>>>> it needed to be done. A couple committers spoke up to say we didn't
>>>>>> think it was sensitive enough to warrant the private discussion but
>>>>>> ultimately there was broad consensus on the implementation and the
>>>>>> change itself. One of those (let us all celebrate) extremely rare
>>>>>> times where there wasn't opportunity for broad community input.
>>>>>>
>>>>>> Creating a view on _users that pulls the relevant parts of a user
>>>>>> document out is the way forward for public profiles, I think.
>>>>>> If someone would write a blog post showing how that works it'd be
>>>>>> great. In retrospect this would have been a great thing to do weeks
>>>>>> ago. Lesson learned.
>>>>>
>>>>> Just to be clear I don't want to dismiss your concerns. If you believe this
>>>>> needs a config option rather than just documentation now is a good time to
>>>>> speak up loudly since the vote was aborted.
>>>>
>>>> Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
>>>>
>>>> I tested your suggestion, however I do not think it is possible.
>>>> Non-admins cannot access a view.
>>>>
>>>> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
>>>> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
>>>> {"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>>>>
>>>> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
>>>> HTTP/1.1 403 Forbidden
>>>> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
>>>> Date: Sat, 11 Feb 2012 02:57:43 GMT
>>>> Content-Type: text/plain; charset=utf-8
>>>> Content-Length: 102
>>>> Cache-Control: must-revalidate
>>>>
>>>> {"error":"forbidden","reason":"Only admins can access design document
>>>> actions for system databases."}
>>>>
>>> Yes that's by design.
>>>
>>> - benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Paul Davis <pa...@gmail.com>.
So yeah. Numbers are hard.
Firstly, anyone that mentioned RFC 4627 or JavaScript behavior is
walking down a path entirely orthogonal to the issue at hand. Jason
almost had it when he talked about them being different but then he
went off on some weird tangent and lost me.
In a nutshell, the issue is this:
CPU's work with bits. Humans (and JSON sorta) work with numbers as a
string of numerals with some punctuation. This is a lossy conversion.
So, back to the details.
COUCHDB-1407 reports that ejson now encodes the value "1.0" as "1".
While we can wax philosophically about this, the bottom line is that
this breaks a level of equality. Specifically:
1> ejson:decode(ejson:encode(1.0)) =:= 1.0.
false
This is precisely because the %g formatting used underneath removes
trailing zeros and decimal points.
On the face of it, this is bad. And I agree. There's a simple enough
fix (and its not what Bob Newson suggested, but I'm going to leave him
hanging for a bit).
But, before we get all crazy, we should contemplate a few other fun cases:
1. Both mochijson2 and ejson change some number representations
5> mochijson2:encode(mochijson2:decode("1E1")) =:= "1E1".
false
6> ejson:encode(ejson:decode("1E1")) =:= "1E1".
false
2. Both mochijson2 and ejson turn numbers with exponents into IEEE-754
internally
7> ejson:decode("1E1") =:= 10.
false
8> mochijson2:decode("1E1") =:= 10.
false
3. Others but I'm tired from staring at math.
Basically, the end result is that we can match mochijson2's decoder
damn near identically (At least, I know of no known differences in
decoding in Jiffy). But now we get to the hard part.
Mochijson2 does some fancy ass magic for encoding IEEE-754 values. And
when I say fancy, I mean, implements an algorithm published in some
random paper from 1996 based on the paper's author's Scheme
implementation. I spent about twelve hours today trying to duplicate
before I realized that it depends on having an integral type that can
represent values with more than 64 bits (which made me sad).
EIther way, this is dark voodoo. Anyone that's interested can checkout
mochinum:digits/1 and the supporting functions for some mind bending
looks into IEEE-754 representations.
Anyway, bottom line is that 1.0 should be encoded as "1.0". The fix is
simply to just check for a decimal point and append one if its not
there. This is what Yajl does and Python appears to behave similarly.
The patch for Jiffy is at [1] and shows the general idea.
Also, for those still holding on to why %f is not a valid fix, the
reason is the same as why %g is wrong (and why it needs to be %0.20g.
printf and friends by default will round to the sixth decimal places.
So, 0.123456789 would get encoded as "0.123457" which loses precision.
Also, with that patch for Jiffy we never lose precision but the
eyesore is that we encoded 0.1 as "0.10000000000888" (Roughly). Some
people find that offensive but I don't really care enough to learn
arbitrary precision math routines so people can have slightly prettier
JSON. And I say that after having spent all day trying to make it
work.
So, yeah. Fix is simple enough.
Also, food for thought: A JSON parser/serializer pair that converts
all numbers to 42 is technically compliant with the JSON spec.
[1] https://github.com/davisp/jiffy/commit/5042cc946008ee413cc66b9b0addcf33ecd2fd93
On Sat, Feb 11, 2012 at 8:32 AM, Robert Newson <rn...@apache.org> wrote:
> I'd like some opinions on whether COUCHDB-1407 constitutes a release
> blocking issue. Yes, I understand that the JSON spec is very weak on
> numbers, blah blah boo splat. Is this because of the switch to ejson?
> Is jiffy more compatible on this score?
>
> For my part, I'm close to considering it a release-blocking
> regression. At the very least this change should be included at
> http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
> but I'd rather it was fixed.
>
> B.
>
> On 11 February 2012 10:44, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Sat, Feb 11, 2012 at 4:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
>>>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>>>>
>>>>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>>>>> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>>>>> > and I asked around. If memory serves, Randall happened to be on at the
>>>>> > time and he asked me the same question you just did. I said I never
>>>>> > saw an RFC email and that's when he realized it was not done publicly.
>>>>>
>>>>> I was aware the entire time, but I think the motivation is sound and
>>>>> it needed to be done. A couple committers spoke up to say we didn't
>>>>> think it was sensitive enough to warrant the private discussion but
>>>>> ultimately there was broad consensus on the implementation and the
>>>>> change itself. One of those (let us all celebrate) extremely rare
>>>>> times where there wasn't opportunity for broad community input.
>>>>>
>>>>> Creating a view on _users that pulls the relevant parts of a user
>>>>> document out is the way forward for public profiles, I think.
>>>>> If someone would write a blog post showing how that works it'd be
>>>>> great. In retrospect this would have been a great thing to do weeks
>>>>> ago. Lesson learned.
>>>>
>>>> Just to be clear I don't want to dismiss your concerns. If you believe this
>>>> needs a config option rather than just documentation now is a good time to
>>>> speak up loudly since the vote was aborted.
>>>
>>> Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
>>>
>>> I tested your suggestion, however I do not think it is possible.
>>> Non-admins cannot access a view.
>>>
>>> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
>>> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
>>> {"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>>>
>>> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
>>> HTTP/1.1 403 Forbidden
>>> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
>>> Date: Sat, 11 Feb 2012 02:57:43 GMT
>>> Content-Type: text/plain; charset=utf-8
>>> Content-Length: 102
>>> Cache-Control: must-revalidate
>>>
>>> {"error":"forbidden","reason":"Only admins can access design document
>>> actions for system databases."}
>>>
>> Yes that's by design.
>>
>> - benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 9:58 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Feb 12, 2012 at 3:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> tl;dr = Minor disagreement with Benoit but happy to go with his decision.
>>
>> On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
>>>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> well as a database, CouchDB shouldn't change the way data are saved
>>>>> in. I expect that the number I saved under the json type Number [1]
>>>>> defined by the spec [2] is correctly saved and returned as is. No
>>>>> roundtrip or precision lost should happen.
>>>>
>>>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
>>>> numbers. JavaScript standards are as relevant as FORTRAN standards.
>>>> But may we continue that discussion in JIRA?
>>>>
>>> I don't follow. JSON describes a number type, and refers to another
>>> iso standard too. How it's incoherent.
>>
>> I could be wrong but I don't see a reference to an ISO or similar
>> standard. I am reading RFC 4627.
>>
> The spec let me think that number should follow the ECMA-754 [1] . But
> i will double check.
>
> Anyway for me a document is a data I post on the disc and it seems
> reasonable to get the same result when I want to get it back.
That is a strong point.
I wonder if my original opinion may be "right" only in some trivial
sense; but difficult for users. CouchDB should be relaxing.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Feb 12, 2012 at 18:30, Robert Newson <ro...@gmail.com> wrote:
> I'm in favor of adding it to breaking changes and keeping the new
> behaviour. Both ejson and jiffy use %g to encode numbers. This favors
> a shorter encoding. On reflection, this is more desirable than
> pretending that json distinguishes between ints and floats.
JSON does distinguish between those: a JSON number that includes a "."
character obviously denotes a float, while one with a "." character
denotes an integer.
The JSON spec does not include any information on how numbers are to
be interpreted, so CouchDB should try to refrain from guessing.
Cheers,
Dirkjan
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Feb 13, 2012 at 12:30 AM, Robert Newson <ro...@gmail.com> wrote:
> I'm in favor of adding it to breaking changes and keeping the new
> behaviour. Both ejson and jiffy use %g to encode numbers. This favors
> a shorter encoding. On reflection, this is more desirable than
> pretending that json distinguishes between ints and floats.
Hi, Bob. Do you remember grade school science class? 1 is not the same
as 1.0, because the latter is a value with two significant figures.
When CouchDB is used with instrumentation and laboratory data, people
may care that 1.0 remains just so. Their data is not the real number
one, but the JSON expression one point zero.
Noah, "JSON" can no more mess up your numbers than utf-8 can. It is
simply an encoding format with no inherent size restriction. The issue
is whether *CouchDB* is messing up numbers through a decode/encode
round-trip.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 6:30 PM, Robert Newson <ro...@gmail.com> wrote:
> [..] On reflection, this is more desirable than
> pretending that json distinguishes between ints and floats.
>
Why? (or, can you share this reflection ? ;)
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Robert Newson <ro...@gmail.com>.
I'm in favor of adding it to breaking changes and keeping the new
behaviour. Both ejson and jiffy use %g to encode numbers. This favors
a shorter encoding. On reflection, this is more desirable than
pretending that json distinguishes between ints and floats.
Sent from my iPhone
On 12 Feb 2012, at 16:49, Noah Slater <ns...@tumbolia.org> wrote:
> I've been over this before:
>
> http://code.google.com/p/simplejson/issues/detail?id=34
>
>
> From Bob Ippolito:
>
> Try alert(2.2000000000000002 == 2.2) in ANY browser. It will say true.
>> JavaScript uses IEEE double for Number, always has, always will.
>
>
> The general consensus seems to be that if you don't want JSON messing
> around with your numbers, then you encode them as strings. Otherwise,
> unless you're using integers, expect weirdness.
>
> However, I'm not sure I understand our choices here.
>
> Could someone explain the choices we have, with a summary of what the net
> result would be?
>
> On Sun, Feb 12, 2012 at 2:58 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> On Sun, Feb 12, 2012 at 3:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
>>> tl;dr = Minor disagreement with Benoit but happy to go with his decision.
>>>
>>> On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>>> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com>
>> wrote:
>>>>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>>>>> well as a database, CouchDB shouldn't change the way data are saved
>>>>>> in. I expect that the number I saved under the json type Number [1]
>>>>>> defined by the spec [2] is correctly saved and returned as is. No
>>>>>> roundtrip or precision lost should happen.
>>>>>
>>>>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
>>>>> numbers. JavaScript standards are as relevant as FORTRAN standards.
>>>>> But may we continue that discussion in JIRA?
>>>>>
>>>> I don't follow. JSON describes a number type, and refers to another
>>>> iso standard too. How it's incoherent.
>>>
>>> I could be wrong but I don't see a reference to an ISO or similar
>>> standard. I am reading RFC 4627.
>>>
>> The spec let me think that number should follow the ECMA-754 [1] . But
>> i will double check.
>>
>> Anyway for me a document is a data I post on the disc and it seems
>> reasonable to get the same result when I want to get it back.
>>
>> If it's not a regression, it isn't really a blocker I think. But I
>> think we should definitely fix it.
>>
>> - benoît
>>
>> [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935
>>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 5:48 PM, Noah Slater <ns...@tumbolia.org> wrote:
> I've been over this before:
>
> http://code.google.com/p/simplejson/issues/detail?id=34
>
>
> From Bob Ippolito:
>
> Try alert(2.2000000000000002 == 2.2) in ANY browser. It will say true.
>> JavaScript uses IEEE double for Number, always has, always will.
>
>
> The general consensus seems to be that if you don't want JSON messing
> around with your numbers, then you encode them as strings. Otherwise,
> unless you're using integers, expect weirdness.
>
> However, I'm not sure I understand our choices here.
>
> Could someone explain the choices we have, with a summary of what the net
> result would be?
>
Well i think the concern is biased. the "alert(2.2000000000000002 ==
2.2) in ANY browser" is also true in python :
>>> 2.2000000000000002 == 2.2
True
But that's not the real question. If we don't store the number like it
was given in couchdb it means we are changing the information, which
is by itself a problem. It also may be a problem for those who need to
have this big precision in their application and it may be a problem
for the future uses of this data when the raw version have been lost.
- Storing as string is okish, though why i should transform to and
from a string when I just wanted to give a number and I had a number
at first?
- We could be better than javascript, it's true that
2.2000000000000002 == 2.2, but it is also true that 2.2 ==
2.2000000000000002, so we can store the precision. and imo that is a
MUST have.
Why can't we do the second actually in jiffy or ejson ? Technically speaking?
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Feb 12, 2012 at 17:48, Noah Slater <ns...@tumbolia.org> wrote:
> Try alert(2.2000000000000002 == 2.2) in ANY browser. It will say true.
>> JavaScript uses IEEE double for Number, always has, always will.
>
> The general consensus seems to be that if you don't want JSON messing
> around with your numbers, then you encode them as strings. Otherwise,
> unless you're using integers, expect weirdness.
The problem with that is that JSON != JavaScript. If CouchDB is a JSON
store, it should properly round-trip my JSON. How JavaScript would
handle my JSON seems unrelated to how a theoretical JSON store would
handle it. I prefer that CouchDB acts as much like a theoretical JSON
store as possible.
Cheers,
Dirkajn
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
I've been over this before:
http://code.google.com/p/simplejson/issues/detail?id=34
>From Bob Ippolito:
Try alert(2.2000000000000002 == 2.2) in ANY browser. It will say true.
> JavaScript uses IEEE double for Number, always has, always will.
The general consensus seems to be that if you don't want JSON messing
around with your numbers, then you encode them as strings. Otherwise,
unless you're using integers, expect weirdness.
However, I'm not sure I understand our choices here.
Could someone explain the choices we have, with a summary of what the net
result would be?
On Sun, Feb 12, 2012 at 2:58 PM, Benoit Chesneau <bc...@gmail.com>wrote:
> On Sun, Feb 12, 2012 at 3:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
> > tl;dr = Minor disagreement with Benoit but happy to go with his decision.
> >
> > On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> >> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com>
> wrote:
> >>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>>> well as a database, CouchDB shouldn't change the way data are saved
> >>>> in. I expect that the number I saved under the json type Number [1]
> >>>> defined by the spec [2] is correctly saved and returned as is. No
> >>>> roundtrip or precision lost should happen.
> >>>
> >>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
> >>> numbers. JavaScript standards are as relevant as FORTRAN standards.
> >>> But may we continue that discussion in JIRA?
> >>>
> >> I don't follow. JSON describes a number type, and refers to another
> >> iso standard too. How it's incoherent.
> >
> > I could be wrong but I don't see a reference to an ISO or similar
> > standard. I am reading RFC 4627.
> >
> The spec let me think that number should follow the ECMA-754 [1] . But
> i will double check.
>
> Anyway for me a document is a data I post on the disc and it seems
> reasonable to get the same result when I want to get it back.
>
> If it's not a regression, it isn't really a blocker I think. But I
> think we should definitely fix it.
>
> - benoît
>
> [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 3:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
> tl;dr = Minor disagreement with Benoit but happy to go with his decision.
>
> On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
>>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> well as a database, CouchDB shouldn't change the way data are saved
>>>> in. I expect that the number I saved under the json type Number [1]
>>>> defined by the spec [2] is correctly saved and returned as is. No
>>>> roundtrip or precision lost should happen.
>>>
>>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
>>> numbers. JavaScript standards are as relevant as FORTRAN standards.
>>> But may we continue that discussion in JIRA?
>>>
>> I don't follow. JSON describes a number type, and refers to another
>> iso standard too. How it's incoherent.
>
> I could be wrong but I don't see a reference to an ISO or similar
> standard. I am reading RFC 4627.
>
The spec let me think that number should follow the ECMA-754 [1] . But
i will double check.
Anyway for me a document is a data I post on the disc and it seems
reasonable to get the same result when I want to get it back.
If it's not a regression, it isn't really a blocker I think. But I
think we should definitely fix it.
- benoît
[1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
tl;dr = Minor disagreement with Benoit but happy to go with his decision.
On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> well as a database, CouchDB shouldn't change the way data are saved
>>> in. I expect that the number I saved under the json type Number [1]
>>> defined by the spec [2] is correctly saved and returned as is. No
>>> roundtrip or precision lost should happen.
>>
>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
>> numbers. JavaScript standards are as relevant as FORTRAN standards.
>> But may we continue that discussion in JIRA?
>>
> I don't follow. JSON describes a number type, and refers to another
> iso standard too. How it's incoherent.
I could be wrong but I don't see a reference to an ISO or similar
standard. I am reading RFC 4627.
Anyway, sorry to be unclear in the last post. The RFC has a type
called "number" however it is not the same as programming language
numeric types (Number, int, double, etc.). Like ink on paper, JSON
"numbers" are symbols, representing the actual numbers.
Doxiadis and Papadimitriou have Bertrand Russel saying,
What is "3" but the set of all sets with three elements?
"Three-ness" is the common property of three umbrellas, three horses...
Three hats...
Three cookies.
When we parse JSON, we convert the symbols into something else:
perhaps IEEE 754. But our eyes and brain also decode JSON, and our
brains represents the numbers, independent of the IEEE. That is valid,
too.
JSON numbers are basically some numerals, a dot, more numerals, and an
exponent. There are no size limits. So the numbers are more properly
arbitrary precision decimals.
I have argued that, as long as Couch does not change the real,
underlying number--the essense--then it is fine; but others have made
reasonable points to the contrary.
Final thought: IMHO it's not a blocker but I gladly yield to the the
community's consensus.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>> well as a database, CouchDB shouldn't change the way data are saved
>> in. I expect that the number I saved under the json type Number [1]
>> defined by the spec [2] is correctly saved and returned as is. No
>> roundtrip or precision lost should happen.
>
> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
> numbers. JavaScript standards are as relevant as FORTRAN standards.
> But may we continue that discussion in JIRA?
>
I don't follow. JSON describes a number type, and refers to another
iso standard too. How it's incoherent.
> *This* discussion is whether it is a blocker. I think it may become
> moot. Bob N. has a simple fix which will probably close the bug.
>
Such type of discussion should happen on the ml rather than on jira
imo. The simple fix fix the obvious but it's fixing the full thing
imo. One other possibility would e having the JSON backend pluggable
at some point so we could also just use the erlang one.
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> well as a database, CouchDB shouldn't change the way data are saved
> in. I expect that the number I saved under the json type Number [1]
> defined by the spec [2] is correctly saved and returned as is. No
> roundtrip or precision lost should happen.
Okay. "JSON type Number" is incoherent. JSON has only numerals, no
numbers. JavaScript standards are as relevant as FORTRAN standards.
But may we continue that discussion in JIRA?
*This* discussion is whether it is a blocker. I think it may become
moot. Bob N. has a simple fix which will probably close the bug.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Feb 12, 2012 at 10:46 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Sun, Feb 12, 2012 at 02:15, Jason Smith <jh...@iriscouch.com> wrote:
>> Does CouchDB store my **JSON** (and mutate it minimally, for _rev)?
>>
>> Or does CouchDB store my **data**, where JSON is simply how we express
>> the underlying "stuff" to be stored?
>
> Yeah, I thought a little further about it during my night's sleep as
> well. I checked the JSON RFC, and it expresses no Number model; just
> the representation. The Number model under which 1.0 === 1 is
> JavaScript's, not JSON's. Therefore, it is impossible to conclude
> equivalence for any two Numbers in JSON notation, and CouchDB should
> roundtrip numbers as close to the original representation as possible.
>
> Cheers,
>
> Dirkjan
well as a database, CouchDB shouldn't change the way data are saved
in. I expect that the number I saved under the json type Number [1]
defined by the spec [2] is correctly saved and returned as is. No
roundtrip or precision lost should happen.
- benoît
[1] Number type has exactly 18437736874454810627 (that is,
2^64-2^53+3) values, representing the double- precision 64-bit format
IEEE 754 values as specified in the IEEE Standard for Binary
Floating-Point Arithmetic, except that the 9007199254740990 (that is,
2^53-2) distinct
[2] http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Feb 12, 2012 at 02:15, Jason Smith <jh...@iriscouch.com> wrote:
> Does CouchDB store my **JSON** (and mutate it minimally, for _rev)?
>
> Or does CouchDB store my **data**, where JSON is simply how we express
> the underlying "stuff" to be stored?
Yeah, I thought a little further about it during my night's sleep as
well. I checked the JSON RFC, and it expresses no Number model; just
the representation. The Number model under which 1.0 === 1 is
JavaScript's, not JSON's. Therefore, it is impossible to conclude
equivalence for any two Numbers in JSON notation, and CouchDB should
roundtrip numbers as close to the original representation as possible.
Cheers,
Dirkjan
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sun, Feb 12, 2012 at 3:25 AM, Robert Newson <rn...@apache.org> wrote:
> Jason's point, I believe, is that there is no distinction between
> types of numbers in JSON.
>
> It's an easy tweak to the encoder to make
> ejson:decode(ejson:encode(1.0)) =:= 1.0, though. I'd like to hear
> arguments for and against before we fire up round 2.
That is correct.
After a night's sleep, I better appreciate the argument against my
response in JIRA.
Does CouchDB store my **JSON** (and mutate it minimally, for _rev)?
Or does CouchDB store my **data**, where JSON is simply how we express
the underlying "stuff" to be stored?
IMO it's the second; but for this discussion (whether it should be a
blocker), it seems at worst a breaking change, not a blocker.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Robert Newson <rn...@apache.org>.
Jason's point, I believe, is that there is no distinction between
types of numbers in JSON.
It's an easy tweak to the encoder to make
ejson:decode(ejson:encode(1.0)) =:= 1.0, though. I'd like to hear
arguments for and against before we fire up round 2.
B.
On 11 February 2012 18:33, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Sat, Feb 11, 2012 at 16:25, Jason Smith <jh...@iriscouch.com> wrote:
>> I suggested it was not a bug. One might argue that Couch should echo
>> back exactly what you give it. I can see that point but am not
>> persuaded. The bug is Python's deserializer being too clever. Since
>> Python is widespread, it is a maybe a breaking change, but not a
>> blocker.
>
> I'm pretty sure I ran into this problem once and checked that CouchDB
> did what I felt was right (i.e. preserve number type). I think I even
> asked about it on the IRC channel where it was also asserted that
> CouchDB did this correctly. It would be a pretty big pain if this
> changed.
>
> Cheers,
>
> Dirkjan
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sat, Feb 11, 2012 at 16:25, Jason Smith <jh...@iriscouch.com> wrote:
> I suggested it was not a bug. One might argue that Couch should echo
> back exactly what you give it. I can see that point but am not
> persuaded. The bug is Python's deserializer being too clever. Since
> Python is widespread, it is a maybe a breaking change, but not a
> blocker.
I'm pretty sure I ran into this problem once and checked that CouchDB
did what I felt was right (i.e. preserve number type). I think I even
asked about it on the IRC channel where it was also asserted that
CouchDB did this correctly. It would be a pretty big pain if this
changed.
Cheers,
Dirkjan
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sat, Feb 11, 2012 at 2:32 PM, Robert Newson <rn...@apache.org> wrote:
> I'd like some opinions on whether COUCHDB-1407 constitutes a release
> blocking issue. Yes, I understand that the JSON spec is very weak on
> numbers, blah blah boo splat. Is this because of the switch to ejson?
> Is jiffy more compatible on this score?
Hi, Bob. I hadn't noticed that ticket. It's interesting. I posted my
response on there.
I suggested it was not a bug. One might argue that Couch should echo
back exactly what you give it. I can see that point but am not
persuaded. The bug is Python's deserializer being too clever. Since
Python is widespread, it is a maybe a breaking change, but not a
blocker.
IMHO.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Feb 11, 2012 at 3:32 PM, Robert Newson <rn...@apache.org> wrote:
> I'd like some opinions on whether COUCHDB-1407 constitutes a release
> blocking issue. Yes, I understand that the JSON spec is very weak on
> numbers, blah blah boo splat. Is this because of the switch to ejson?
> Is jiffy more compatible on this score?
>
> For my part, I'm close to considering it a release-blocking
> regression. At the very least this change should be included at
> http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
> but I'd rather it was fixed.
>
> B.
Imo, it's a release blocking:
1. it's a regression
2. we shouldn't change the way the number has been inserted until it
follows the spec.
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Robert Newson <rn...@apache.org>.
I'd like some opinions on whether COUCHDB-1407 constitutes a release
blocking issue. Yes, I understand that the JSON spec is very weak on
numbers, blah blah boo splat. Is this because of the switch to ejson?
Is jiffy more compatible on this score?
For my part, I'm close to considering it a release-blocking
regression. At the very least this change should be included at
http://wiki.apache.org/couchdb/Breaking_changes#Changes_Between_1.1.0_and_1.2.0
but I'd rather it was fixed.
B.
On 11 February 2012 10:44, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sat, Feb 11, 2012 at 4:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
>>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>>>
>>>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>>>> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>>>> > and I asked around. If memory serves, Randall happened to be on at the
>>>> > time and he asked me the same question you just did. I said I never
>>>> > saw an RFC email and that's when he realized it was not done publicly.
>>>>
>>>> I was aware the entire time, but I think the motivation is sound and
>>>> it needed to be done. A couple committers spoke up to say we didn't
>>>> think it was sensitive enough to warrant the private discussion but
>>>> ultimately there was broad consensus on the implementation and the
>>>> change itself. One of those (let us all celebrate) extremely rare
>>>> times where there wasn't opportunity for broad community input.
>>>>
>>>> Creating a view on _users that pulls the relevant parts of a user
>>>> document out is the way forward for public profiles, I think.
>>>> If someone would write a blog post showing how that works it'd be
>>>> great. In retrospect this would have been a great thing to do weeks
>>>> ago. Lesson learned.
>>>
>>> Just to be clear I don't want to dismiss your concerns. If you believe this
>>> needs a config option rather than just documentation now is a good time to
>>> speak up loudly since the vote was aborted.
>>
>> Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
>>
>> I tested your suggestion, however I do not think it is possible.
>> Non-admins cannot access a view.
>>
>> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
>> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
>> {"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>>
>> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
>> HTTP/1.1 403 Forbidden
>> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
>> Date: Sat, 11 Feb 2012 02:57:43 GMT
>> Content-Type: text/plain; charset=utf-8
>> Content-Length: 102
>> Cache-Control: must-revalidate
>>
>> {"error":"forbidden","reason":"Only admins can access design document
>> actions for system databases."}
>>
> Yes that's by design.
>
> - benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Feb 11, 2012 at 4:00 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
>> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>>
>>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>>> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>>> > and I asked around. If memory serves, Randall happened to be on at the
>>> > time and he asked me the same question you just did. I said I never
>>> > saw an RFC email and that's when he realized it was not done publicly.
>>>
>>> I was aware the entire time, but I think the motivation is sound and
>>> it needed to be done. A couple committers spoke up to say we didn't
>>> think it was sensitive enough to warrant the private discussion but
>>> ultimately there was broad consensus on the implementation and the
>>> change itself. One of those (let us all celebrate) extremely rare
>>> times where there wasn't opportunity for broad community input.
>>>
>>> Creating a view on _users that pulls the relevant parts of a user
>>> document out is the way forward for public profiles, I think.
>>> If someone would write a blog post showing how that works it'd be
>>> great. In retrospect this would have been a great thing to do weeks
>>> ago. Lesson learned.
>>
>> Just to be clear I don't want to dismiss your concerns. If you believe this
>> needs a config option rather than just documentation now is a good time to
>> speak up loudly since the vote was aborted.
>
> Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
>
> I tested your suggestion, however I do not think it is possible.
> Non-admins cannot access a view.
>
> $ curlp http://admin:admin@localhost:5984/_users/_design/public -d
> '{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
> {"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
>
> $ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
> HTTP/1.1 403 Forbidden
> Server: CouchDB/1.2.0 (Erlang OTP/R15B)
> Date: Sat, 11 Feb 2012 02:57:43 GMT
> Content-Type: text/plain; charset=utf-8
> Content-Length: 102
> Cache-Control: must-revalidate
>
> {"error":"forbidden","reason":"Only admins can access design document
> actions for system databases."}
>
Yes that's by design.
- benoît
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Sat, Feb 11, 2012 at 3:06 AM, Randall Leeds <ra...@gmail.com> wrote:
> On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>>
>> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
>> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
>> > and I asked around. If memory serves, Randall happened to be on at the
>> > time and he asked me the same question you just did. I said I never
>> > saw an RFC email and that's when he realized it was not done publicly.
>>
>> I was aware the entire time, but I think the motivation is sound and
>> it needed to be done. A couple committers spoke up to say we didn't
>> think it was sensitive enough to warrant the private discussion but
>> ultimately there was broad consensus on the implementation and the
>> change itself. One of those (let us all celebrate) extremely rare
>> times where there wasn't opportunity for broad community input.
>>
>> Creating a view on _users that pulls the relevant parts of a user
>> document out is the way forward for public profiles, I think.
>> If someone would write a blog post showing how that works it'd be
>> great. In retrospect this would have been a great thing to do weeks
>> ago. Lesson learned.
>
> Just to be clear I don't want to dismiss your concerns. If you believe this
> needs a config option rather than just documentation now is a good time to
> speak up loudly since the vote was aborted.
Thanks. I am concerned. To me, the change is noteworthy but not a showstopper.
I tested your suggestion, however I do not think it is possible.
Non-admins cannot access a view.
$ curlp http://admin:admin@localhost:5984/_users/_design/public -d
'{"views":{"all":{"map":"function(doc) { emit(doc._id, doc) }"}}}'
{"ok":true,"id":"_design/public","rev":"1-f605d1ea7825645132f54a91a76a1ddc"}
$ curl -i http://user:user@localhost:5984/_users/_design/public/_view/all
HTTP/1.1 403 Forbidden
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Sat, 11 Feb 2012 02:57:43 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 102
Cache-Control: must-revalidate
{"error":"forbidden","reason":"Only admins can access design document
actions for system databases."}
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Randall Leeds <ra...@gmail.com>.
On Feb 9, 2012 6:09 PM, "Randall Leeds" <ra...@gmail.com> wrote:
>
> On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
> > Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
> > and I asked around. If memory serves, Randall happened to be on at the
> > time and he asked me the same question you just did. I said I never
> > saw an RFC email and that's when he realized it was not done publicly.
>
> I was aware the entire time, but I think the motivation is sound and
> it needed to be done. A couple committers spoke up to say we didn't
> think it was sensitive enough to warrant the private discussion but
> ultimately there was broad consensus on the implementation and the
> change itself. One of those (let us all celebrate) extremely rare
> times where there wasn't opportunity for broad community input.
>
> Creating a view on _users that pulls the relevant parts of a user
> document out is the way forward for public profiles, I think.
> If someone would write a blog post showing how that works it'd be
> great. In retrospect this would have been a great thing to do weeks
> ago. Lesson learned.
Just to be clear I don't want to dismiss your concerns. If you believe this
needs a config option rather than just documentation now is a good time to
speak up loudly since the vote was aborted.
>
> Now to test!
>
> -R
>
> >
> > I am pleased and grateful for the 1.2 release. It's remarkable! I'll
> > simply remind the community, don't email a plus-one just because the
> > unit tests pass. Install your application! Test your application! If
> > you use _users in your Couch app, this will be the most significant
> > breaking change since the 0.9 release.
> >
> > On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org>
wrote:
> >> Did you bring this up on the RFC thread or in private, Jason?
> >>
> >> On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >>
> >>> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org>
wrote:
> >>> > Hello,
> >>> >
> >>> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
> >>> round.
> >>>
> >>> Documents in the _users database are no longer publicly readable.
> >>>
> >>> I understand that there was no public RFC about this due to its
> >>> security implications?
> >>>
> >>> Iris Couch users have been running the 1.2.x beta builds for a few
> >>> ekes and this is the top point of feedback. People have to rewrite
> >>> their Couch apps, in particular because most of Chris's projects and
> >>> examples uses _user to keep public profiles (nickname, Gravatar URL,
> >>> etc.).
> >>>
> >>> I suppose this is old news. The decision is good. It's a documented
> >>> breaking change. Fine. I hope there isn't blowback though.
> >>>
> >>> --
> >>> Iris Couch
> >>>
> >
> >
> >
> > --
> > Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Randall Leeds <ra...@gmail.com>.
On Thu, Feb 9, 2012 at 17:48, Jason Smith <jh...@iriscouch.com> wrote:
> Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
> and I asked around. If memory serves, Randall happened to be on at the
> time and he asked me the same question you just did. I said I never
> saw an RFC email and that's when he realized it was not done publicly.
I was aware the entire time, but I think the motivation is sound and
it needed to be done. A couple committers spoke up to say we didn't
think it was sensitive enough to warrant the private discussion but
ultimately there was broad consensus on the implementation and the
change itself. One of those (let us all celebrate) extremely rare
times where there wasn't opportunity for broad community input.
Creating a view on _users that pulls the relevant parts of a user
document out is the way forward for public profiles, I think.
If someone would write a blog post showing how that works it'd be
great. In retrospect this would have been a great thing to do weeks
ago. Lesson learned.
Now to test!
-R
>
> I am pleased and grateful for the 1.2 release. It's remarkable! I'll
> simply remind the community, don't email a plus-one just because the
> unit tests pass. Install your application! Test your application! If
> you use _users in your Couch app, this will be the most significant
> breaking change since the 0.9 release.
>
> On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org> wrote:
>> Did you bring this up on the RFC thread or in private, Jason?
>>
>> On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>
>>> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org> wrote:
>>> > Hello,
>>> >
>>> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
>>> round.
>>>
>>> Documents in the _users database are no longer publicly readable.
>>>
>>> I understand that there was no public RFC about this due to its
>>> security implications?
>>>
>>> Iris Couch users have been running the 1.2.x beta builds for a few
>>> ekes and this is the top point of feedback. People have to rewrite
>>> their Couch apps, in particular because most of Chris's projects and
>>> examples uses _user to keep public profiles (nickname, Gravatar URL,
>>> etc.).
>>>
>>> I suppose this is old news. The decision is good. It's a documented
>>> breaking change. Fine. I hope there isn't blowback though.
>>>
>>> --
>>> Iris Couch
>>>
>
>
>
> --
> Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
I was referring to the 1.2.0 RFC where I was hoping to catch any potential
objections such as this. I will let someone else, more familiar with this
particular change, take this up.
On Fri, Feb 10, 2012 at 1:48 AM, Jason Smith <jh...@iriscouch.com> wrote:
> Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
> and I asked around. If memory serves, Randall happened to be on at the
> time and he asked me the same question you just did. I said I never
> saw an RFC email and that's when he realized it was not done publicly.
>
> I am pleased and grateful for the 1.2 release. It's remarkable! I'll
> simply remind the community, don't email a plus-one just because the
> unit tests pass. Install your application! Test your application! If
> you use _users in your Couch app, this will be the most significant
> breaking change since the 0.9 release.
>
> On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org> wrote:
> > Did you bring this up on the RFC thread or in private, Jason?
> >
> > On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com> wrote:
> >
> >> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> >> > Hello,
> >> >
> >> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
> >> round.
> >>
> >> Documents in the _users database are no longer publicly readable.
> >>
> >> I understand that there was no public RFC about this due to its
> >> security implications?
> >>
> >> Iris Couch users have been running the 1.2.x beta builds for a few
> >> ekes and this is the top point of feedback. People have to rewrite
> >> their Couch apps, in particular because most of Chris's projects and
> >> examples uses _user to keep public profiles (nickname, Gravatar URL,
> >> etc.).
> >>
> >> I suppose this is old news. The decision is good. It's a documented
> >> breaking change. Fine. I hope there isn't blowback though.
> >>
> >> --
> >> Iris Couch
> >>
>
>
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
Hi, Noah. When I saw it hit Git, I realized it was a breaking change,
and I asked around. If memory serves, Randall happened to be on at the
time and he asked me the same question you just did. I said I never
saw an RFC email and that's when he realized it was not done publicly.
I am pleased and grateful for the 1.2 release. It's remarkable! I'll
simply remind the community, don't email a plus-one just because the
unit tests pass. Install your application! Test your application! If
you use _users in your Couch app, this will be the most significant
breaking change since the 0.9 release.
On Fri, Feb 10, 2012 at 8:25 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Did you bring this up on the RFC thread or in private, Jason?
>
> On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com> wrote:
>
>> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org> wrote:
>> > Hello,
>> >
>> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
>> round.
>>
>> Documents in the _users database are no longer publicly readable.
>>
>> I understand that there was no public RFC about this due to its
>> security implications?
>>
>> Iris Couch users have been running the 1.2.x beta builds for a few
>> ekes and this is the top point of feedback. People have to rewrite
>> their Couch apps, in particular because most of Chris's projects and
>> examples uses _user to keep public profiles (nickname, Gravatar URL,
>> etc.).
>>
>> I suppose this is old news. The decision is good. It's a documented
>> breaking change. Fine. I hope there isn't blowback though.
>>
>> --
>> Iris Couch
>>
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Did you bring this up on the RFC thread or in private, Jason?
On Fri, Feb 10, 2012 at 1:16 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org> wrote:
> > Hello,
> >
> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
> round.
>
> Documents in the _users database are no longer publicly readable.
>
> I understand that there was no public RFC about this due to its
> security implications?
>
> Iris Couch users have been running the 1.2.x beta builds for a few
> ekes and this is the top point of feedback. People have to rewrite
> their Couch apps, in particular because most of Chris's projects and
> examples uses _user to keep public profiles (nickname, Gravatar URL,
> etc.).
>
> I suppose this is old news. The decision is good. It's a documented
> breaking change. Fine. I hope there isn't blowback though.
>
> --
> Iris Couch
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jason Smith <jh...@iriscouch.com>.
On Fri, Feb 10, 2012 at 7:52 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
Documents in the _users database are no longer publicly readable.
I understand that there was no public RFC about this due to its
security implications?
Iris Couch users have been running the 1.2.x beta builds for a few
ekes and this is the top point of feedback. People have to rewrite
their Couch apps, in particular because most of Chris's projects and
examples uses _user to keep public profiles (nickname, Gravatar URL,
etc.).
I suppose this is old news. The decision is good. It's a documented
breaking change. Fine. I hope there isn't blowback though.
--
Iris Couch
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Aborting the vote.
On Fri, Feb 10, 2012 at 2:36 PM, Sam Bisbee <sa...@sbisbee.com> wrote:
> On Thu, Feb 9, 2012 at 7:52 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Happy voting,
> >
> > N
>
> -1 due to errors below and the already mentioned CHANGELOG issues.
>
> Tested on Ubuntu oneiric, amd64, SpiderMonkey 1.8.5-1.0.0-0ubuntu5,
> Erlang 1:14.b.2-dfsg-3ubuntu2
>
> MD5, SHA1, and ASC all verify.
>
> No diff complaints.
>
> `make check` passes
>
> The following Futon tests fail on Chromium 16:
>
> - attachment_ranges
> Assertion failed: expected '"bytes 0-28/29"', got '"bytes 0-29/29"'
> Assertion failed: expected '"29"', got '"30"'
>
> - config
> Assertion 'Default whitelist is empty' failed: expected 'null', got
> '"[{httpd,config_whitelist}, {test,foo}]"'
> Exception raised:
> {"code":101,"name":"NETWORK_ERR","message":"NETWORK_ERR:
> XMLHttpRequest Exception 101"}
>
> - cookie_auth
> Exception raised: {"error":"modification_not_allowed","reason":"This
> config variable is read-only"}
>
> - delayed_commits
> Exception raised: {"error":"modification_not_allowed","reason":"This
> config variable is read-only"}
>
> - design_docs
> Exception raised: {"error":"modification_not_allowed","reason":"This
> config variable is read-only"}
>
> - erlang_views
> Exception raised:
> {"code":101,"name":"NETWORK_ERR","message":"NETWORK_ERR:
> XMLHttpRequest Exception 101"}
>
> - purge
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Assertion failed: rows[2*i].key == i+1
> Assertion failed: rows[(2*i)+1].key == i+1
> Exception raised: {}
>
> Cheers,
>
> --
> Sam Bisbee
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Sam Bisbee <sa...@sbisbee.com>.
On Thu, Feb 9, 2012 at 7:52 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Happy voting,
>
> N
-1 due to errors below and the already mentioned CHANGELOG issues.
Tested on Ubuntu oneiric, amd64, SpiderMonkey 1.8.5-1.0.0-0ubuntu5,
Erlang 1:14.b.2-dfsg-3ubuntu2
MD5, SHA1, and ASC all verify.
No diff complaints.
`make check` passes
The following Futon tests fail on Chromium 16:
- attachment_ranges
Assertion failed: expected '"bytes 0-28/29"', got '"bytes 0-29/29"'
Assertion failed: expected '"29"', got '"30"'
- config
Assertion 'Default whitelist is empty' failed: expected 'null', got
'"[{httpd,config_whitelist}, {test,foo}]"'
Exception raised:
{"code":101,"name":"NETWORK_ERR","message":"NETWORK_ERR:
XMLHttpRequest Exception 101"}
- cookie_auth
Exception raised: {"error":"modification_not_allowed","reason":"This
config variable is read-only"}
- delayed_commits
Exception raised: {"error":"modification_not_allowed","reason":"This
config variable is read-only"}
- design_docs
Exception raised: {"error":"modification_not_allowed","reason":"This
config variable is read-only"}
- erlang_views
Exception raised:
{"code":101,"name":"NETWORK_ERR","message":"NETWORK_ERR:
XMLHttpRequest Exception 101"}
- purge
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Assertion failed: rows[2*i].key == i+1
Assertion failed: rows[(2*i)+1].key == i+1
Exception raised: {}
Cheers,
--
Sam Bisbee
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Robert Newson <rn...@apache.org>.
+1
checksum and sig matches.
make check passes.
Futon test suite passes on Firefox 10.0. All but attachment_ranges
passes on Chrome 17.0.963.46 but that's because of a genuine bug in
Chrome for range requests that exceed entity length.
Erlang R14B04, SpiderMonkey 1.8.5, ICU 4.8.1.1, OS X 10.7.3.
B.
On 10 February 2012 02:20, Noah Slater <ns...@tumbolia.org> wrote:
> Thanks Brian.
>
> You probably want to hope on to IRC and see if you can rope davisp in to
> troubleshooting it for you.
>
> On Fri, Feb 10, 2012 at 2:10 AM, Brian Mitchell <bi...@gmail.com> wrote:
>
>> Seems it was chopped off as my outbox has it attached. Check here:
>>
>> https://gist.github.com/1785525
>>
>>
>> On Thursday, February 9, 2012 at 21:09 , Noah Slater wrote:
>>
>> > Missing your attachment.
>> >
>> > On Fri, Feb 10, 2012 at 1:57 AM, Brian Mitchell <binary42@gmail.com(mailto:
>> binary42@gmail.com)> wrote:
>> >
>> > > On Thursday, February 9, 2012 at 20:38 , Brian Mitchell wrote:
>> > >
>> > > On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
>> > >
>> > > Brian, were you able to follow the test procedure?
>> > >
>> > >
>> > > Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some
>> > > quick tests (running full test suite in a moment).
>> > >
>> > > On make check I get a hang on test/etap/076-file-compression.t for
>> R15B.
>> > > Not sure what's up.
>> > >
>> > > Output of that test is attached.
>>
>>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Thanks Brian.
You probably want to hope on to IRC and see if you can rope davisp in to
troubleshooting it for you.
On Fri, Feb 10, 2012 at 2:10 AM, Brian Mitchell <bi...@gmail.com> wrote:
> Seems it was chopped off as my outbox has it attached. Check here:
>
> https://gist.github.com/1785525
>
>
> On Thursday, February 9, 2012 at 21:09 , Noah Slater wrote:
>
> > Missing your attachment.
> >
> > On Fri, Feb 10, 2012 at 1:57 AM, Brian Mitchell <binary42@gmail.com(mailto:
> binary42@gmail.com)> wrote:
> >
> > > On Thursday, February 9, 2012 at 20:38 , Brian Mitchell wrote:
> > >
> > > On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
> > >
> > > Brian, were you able to follow the test procedure?
> > >
> > >
> > > Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some
> > > quick tests (running full test suite in a moment).
> > >
> > > On make check I get a hang on test/etap/076-file-compression.t for
> R15B.
> > > Not sure what's up.
> > >
> > > Output of that test is attached.
>
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Brian Mitchell <bi...@gmail.com>.
Seems it was chopped off as my outbox has it attached. Check here:
https://gist.github.com/1785525
On Thursday, February 9, 2012 at 21:09 , Noah Slater wrote:
> Missing your attachment.
>
> On Fri, Feb 10, 2012 at 1:57 AM, Brian Mitchell <binary42@gmail.com (mailto:binary42@gmail.com)> wrote:
>
> > On Thursday, February 9, 2012 at 20:38 , Brian Mitchell wrote:
> >
> > On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
> >
> > Brian, were you able to follow the test procedure?
> >
> >
> > Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some
> > quick tests (running full test suite in a moment).
> >
> > On make check I get a hang on test/etap/076-file-compression.t for R15B.
> > Not sure what's up.
> >
> > Output of that test is attached.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Missing your attachment.
On Fri, Feb 10, 2012 at 1:57 AM, Brian Mitchell <bi...@gmail.com> wrote:
> On Thursday, February 9, 2012 at 20:38 , Brian Mitchell wrote:
>
> On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
>
> Brian, were you able to follow the test procedure?
>
>
> Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some
> quick tests (running full test suite in a moment).
>
> On make check I get a hang on test/etap/076-file-compression.t for R15B.
> Not sure what's up.
>
> Output of that test is attached.
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Brian Mitchell <bi...@gmail.com>.
On Thursday, February 9, 2012 at 20:38 , Brian Mitchell wrote:
> On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
> > Brian, were you able to follow the test procedure?
> >
> >
> >
>
>
> Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some quick tests (running full test suite in a moment).
>
On make check I get a hang on test/etap/076-file-compression.t for R15B. Not sure what's up.
Output of that test is attached.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Brian Mitchell <bi...@gmail.com>.
On Thursday, February 9, 2012 at 20:26 , Noah Slater wrote:
> Brian, were you able to follow the test procedure?
>
>
Yes. OS X 10.7.3 with R14B04. It also seems to work on R15B after some quick tests (running full test suite in a moment).
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Noah Slater <ns...@tumbolia.org>.
Brian, were you able to follow the test procedure?
On Fri, Feb 10, 2012 at 1:17 AM, Brian Mitchell <bi...@gmail.com> wrote:
> I've not had any issues with running on that change set. Looking through
> this release form 1.1, I'd say it puts the project in a much improved
> state. +1 for release.
>
>
> On Thursday, February 9, 2012 at 19:52 , Noah Slater wrote:
>
> > Hello,
> >
> > I would like call a vote for the Apache CouchDB 1.2.0 release, first
> round.
> >
> > We encourage the whole community to download and test these release
> > artifacts so that any critical issues can be resolved before the release
> is
> > made. Everyone is free to vote on this release, so get stuck in!
> >
> > We are voting on the following release artifacts:
> >
> > http://people.apache.org/~nslater/dist/1.2.0/
> >
> >
> > These artifacts have been built from the following tree-ish in Git:
> >
> > cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
> >
> >
> > Please follow the test procedure before voting:
> >
> > http://wiki.apache.org/couchdb/Test_procedure
> >
> >
> > Thank you.
> >
> > Happy voting,
> >
> > N
>
>
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Brian Mitchell <bi...@gmail.com>.
I've not had any issues with running on that change set. Looking through this release form 1.1, I'd say it puts the project in a much improved state. +1 for release.
On Thursday, February 9, 2012 at 19:52 , Noah Slater wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/1.2.0/
>
>
> These artifacts have been built from the following tree-ish in Git:
>
> cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
>
>
> Please follow the test procedure before voting:
>
> http://wiki.apache.org/couchdb/Test_procedure
>
>
> Thank you.
>
> Happy voting,
>
> N
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jan Lehnardt <ja...@apache.org>.
On Feb 10, 2012, at 14:35 , Dave Cottlehuber wrote:
> On 10 February 2012 13:54, Dave Cottlehuber <da...@muse.net.nz> wrote:
>> On 10 February 2012 01:52, Noah Slater <ns...@tumbolia.org> wrote:
>>> Hello,
>>>
>>> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
>
> NEWS & CHANGES still have "version has not been released" warnings,
> shouldn't these be removed prior to building the tarball?
Yup. Good catch :)
One more time!
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 10 February 2012 13:54, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 10 February 2012 01:52, Noah Slater <ns...@tumbolia.org> wrote:
>> Hello,
>>
>> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
NEWS & CHANGES still have "version has not been released" warnings,
shouldn't these be removed prior to building the tarball?
A+
Dave
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 10 February 2012 01:52, Noah Slater <ns...@tumbolia.org> wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
On 10 February 2012 01:52, Noah Slater <ns...@tumbolia.org> wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
sig, md5, sha OK
artefacts OK
+1 tested on Mac and Windows
# Mac
ProductName: Mac OS X
ProductVersion: 10.7.3
BuildVersion: 11D50b
Darwin 11.3.0 x86_64 i386
Erlang R15B
ICU 4.8.1.1
SpiderMonkey 1.8.5
## make test
All tests successful.
Files=50, Tests=2917, 480 wallclock secs ( 1.57 usr 0.23 sys + 616.16
cusr 26.59 csys = 644.55 CPU)
Result: PASS
## futon test firefox aurora 11 Mac
verify install OK
test suite OK
## Notes
make test: hung etap/073-changes.t on first run, no recurrences
futon test: erlang bus errors on many init:restart(). I don't see this as a
CouchDB issue nor a blocker - re https://gist.github.com/1199903
# Windows 7 Enterprise, x64
Microsoft Windows [Version 6.1.7601]
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 42 Stepping 7, GenuineIntel
Erlang R14B and R15B + openssl 0.9.8r
ICU 4.6.1
SpiderMonkey 1.8.5
## make test
n/a
## futon test firefox aurora 11 on Mac, firefox 6 on Windows
verify install OK
test suite OK
## Notes
builds up at https://people.apache.org/~dch/dist/1.2.0/
pgp signature from https://people.apache.org/~dch/dist/04F4EE9B.asc
futon test: 2 failures when run over 127.0.0.1; 100% success over LAN
in replication:
{"error":"file_exists",
"reason":"The database could not be created, the file already exists."}
in replicator_db: Assertion failed: expected 'null', got
'{"_id":"foo666","_rev":"2-19d0c28ea169872441d6d33c2c5a6cce","value":666}'
as well.
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Jan Lehnardt <ja...@apache.org>.
On Feb 10, 2012, at 01:52 , Noah Slater wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/1.2.0/
>
>
> These artifacts have been built from the following tree-ish in Git:
>
> cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
>
>
> Please follow the test procedure before voting:
>
> http://wiki.apache.org/couchdb/Test_procedure
>
>
> Thank you.
Thank you Noah and all who helped roll this! :)
> Happy voting,
Tested on Mac OS X 10.7.2, Erlang R14B04, Spidemonkey 1.8.0. make check passes, browser tests all pass in Chrome.
Tested on Ubuntu 11.10 x86_64, R14B02, Spidermonkey 1.8.5. make check passes, browser tests all pass in Firefox.
+1
Lets do this! :)
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Posted by Sebastian Cohnen <se...@googlemail.com>.
OS X 10.7.3, Erlang R15B, SpiderMonkey 1.8.5, ICU 4.8.1.1, Test run in FF 8.0.1
* signatures okay
* make check okay
* browser test suite okay
+1
On 10.02.2012, at 01:52, Noah Slater wrote:
> Hello,
>
> I would like call a vote for the Apache CouchDB 1.2.0 release, first round.
>
> We encourage the whole community to download and test these release
> artifacts so that any critical issues can be resolved before the release is
> made. Everyone is free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/1.2.0/
>
>
> These artifacts have been built from the following tree-ish in Git:
>
> cea48f36d8b088e3fd1c64e2aa1b9d9c742a3b71
>
>
> Please follow the test procedure before voting:
>
> http://wiki.apache.org/couchdb/Test_procedure
>
>
> Thank you.
>
> Happy voting,
>
> N