[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573270#comment-13573270 ] Stefan Kögl commented on COUCHDB-1654: -- When migrating an 1.2.1 instance to 1.3.x for testing purposes, I could query most of the views correctly. For one I reproducably receive the following trace https://friendpaste.com/2iNlKuwxzfNDW3dsYBnqsv. Wohali in #couchdb recommended to add that to this ticket. > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Import Fauxton
> Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan > -- > +1 - Hans
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 9:50 PM, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on > https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan > -- > > -- Iris Couch
[jira] [Commented] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
[ https://issues.apache.org/jira/browse/COUCHDB-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573190#comment-13573190 ] Paul Joseph Davis commented on COUCHDB-1670: Jason and Jens are right here, although I do find it a bit surprising that we actually have an issue here given how erlang treats numbers. My only guess is that we have a guard for is_integer/1 instead of is_number/1 which would badarg on the parsed value (mochijson2 at least would parse that as a float). Couple minor comments on discussion: [~snej] has it right in that we can't expect that JSON will roundtrip byte-for-byte when we have an intermediary translation into an Erlang representation. We already rely on them facts so that we can tell people to sshh when we mutate number representations. [~jhs] Is kinda right but its not just a series of numerals, though its not much more than "looks like a valid number". While the encoding differences aren't quite white space difference levels, they are definitely in below the threshold of what we should tolerate, especially considering what we're using them for. I also have no idea what [~jhs] is talking about with whitespace in the key. If there's truth to that then it sounds like a bug and not just "merely" a json encoding difference. [~jhs] is also quoting Postel's law which is a crock and I have spent much time trying to quash the influence of that terrible idea in the project. The number of times I've gotten pissed trying to remember if its descending=true or reverse=true and checking if I have typos is annoyingly non-zero. [~wohali] is also right in the generic sense that since (hehehe) should not be restricted to a numerical value and if we didn't have what appear to be laten bugs based on that assumption this probably wouldn't even be an issue. And if y'all want to spend more time on this, start investigating round tripping the value 1.1 through a JSON decoder/encoder pair. I'll be here with the tissues when you get to asserting 56bit rounding precisions with the GNU libc strtod assumptions. > Replicator crashes if numbers in checkpoint docs are expressed in scientific > notation > - > > Key: COUCHDB-1670 > URL: https://issues.apache.org/jira/browse/COUCHDB-1670 > Project: CouchDB > Issue Type: Bug > Components: Replication >Reporter: Jens Alfke > > The CouchDB 1.2 replicator process crashes with an Erlang exception when > parsing a checkpoint document read back from a remote database, if numbers in > the document were JSON-encoded in scientific notation instead of as integers. > This includes the properties source_last_seq, end_last_seq, start_last_seq. > That is, the following encoding works fine: > ..., "source_last_seq": 1234567, ... > whereas this completely-equivalent encoding causes an exception: > ..., "source_last_seq": 1.234567e+06, ... > This issue raised its head as a result of a CouchDB-compatible engine I'm > writing (the Couchbase Sync Gateway) which can serve as a passive replication > endpoint. It's implemented in Go, and the Go JSON package has the side effect > of (a) parsing all JSON numbers into type 'double', and (b) encoding all > doubles into JSON using scientific notation if they're more than six digits > long. The net effect is that when CouchDB stores a checkpoint into the Sync > Adapter's database and then later reads it back, it barfs due to the > scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
[ https://issues.apache.org/jira/browse/COUCHDB-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573175#comment-13573175 ] Joan Touzet commented on COUCHDB-1670: -- I think it's an incorrect assumption that since must always be a base 10 number, scientific notation or not. > Replicator crashes if numbers in checkpoint docs are expressed in scientific > notation > - > > Key: COUCHDB-1670 > URL: https://issues.apache.org/jira/browse/COUCHDB-1670 > Project: CouchDB > Issue Type: Bug > Components: Replication >Reporter: Jens Alfke > > The CouchDB 1.2 replicator process crashes with an Erlang exception when > parsing a checkpoint document read back from a remote database, if numbers in > the document were JSON-encoded in scientific notation instead of as integers. > This includes the properties source_last_seq, end_last_seq, start_last_seq. > That is, the following encoding works fine: > ..., "source_last_seq": 1234567, ... > whereas this completely-equivalent encoding causes an exception: > ..., "source_last_seq": 1.234567e+06, ... > This issue raised its head as a result of a CouchDB-compatible engine I'm > writing (the Couchbase Sync Gateway) which can serve as a passive replication > endpoint. It's implemented in Go, and the Go JSON package has the side effect > of (a) parsing all JSON numbers into type 'double', and (b) encoding all > doubles into JSON using scientific notation if they're more than six digits > long. The net effect is that when CouchDB stores a checkpoint into the Sync > Adapter's database and then later reads it back, it barfs due to the > scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
[ https://issues.apache.org/jira/browse/COUCHDB-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573163#comment-13573163 ] Jason Smith commented on COUCHDB-1670: -- Other issues have brought up the meaning of "numbers" in JSON. (For example, the spec just says that numbers are a series of numerals, implying arbitrary precision, not IEEE 754.) I agree with Jens. In the important sense, he **is** returning the same opaque value to CouchDB. He encoded it differently, but IMO those differences are more like insignificant white space in the JSON. (CouchDB does not follow this principle perfectly. IIRC, if you place "insignificant" whitespace in your `_view?key=xxx` query then you will not get a result.) If the Go library does that, this is a good opportunity for CouchDB to become more "liberal in what it accepts." > Replicator crashes if numbers in checkpoint docs are expressed in scientific > notation > - > > Key: COUCHDB-1670 > URL: https://issues.apache.org/jira/browse/COUCHDB-1670 > Project: CouchDB > Issue Type: Bug > Components: Replication >Reporter: Jens Alfke > > The CouchDB 1.2 replicator process crashes with an Erlang exception when > parsing a checkpoint document read back from a remote database, if numbers in > the document were JSON-encoded in scientific notation instead of as integers. > This includes the properties source_last_seq, end_last_seq, start_last_seq. > That is, the following encoding works fine: > ..., "source_last_seq": 1234567, ... > whereas this completely-equivalent encoding causes an exception: > ..., "source_last_seq": 1.234567e+06, ... > This issue raised its head as a result of a CouchDB-compatible engine I'm > writing (the Couchbase Sync Gateway) which can serve as a passive replication > endpoint. It's implemented in Go, and the Go JSON package has the side effect > of (a) parsing all JSON numbers into type 'double', and (b) encoding all > doubles into JSON using scientific notation if they're more than six digits > long. The net effect is that when CouchDB stores a checkpoint into the Sync > Adapter's database and then later reads it back, it barfs due to the > scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1651) Server responds 400 "Exceeded rewrite recursion limit" indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573107#comment-13573107
]
Paul Frazee commented on COUCHDB-1651:
--
I should also mention, I spent some time hitting the routes on the alternative
domain (with no vhost). However, despite hitting the _rewrite paths (and the
recursive subpaths created by my globbed rule) the server continued
functioning. I eventually experienced the bug again, but not until later in the
evening.
> Server responds 400 "Exceeded rewrite recursion limit" indefinitely
> ---
>
> Key: COUCHDB-1651
> URL: https://issues.apache.org/jira/browse/COUCHDB-1651
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Paul Frazee
>
> Running 1.2.1 on Windows 7 as a service.
> hosts file includes "127.0.0.1 grimwire.local"
> CouchDB conf includes vhosts entries:
> grimwire.local:5984/grimwire/_design/grimwire/_rewrite
> grimwire.local:5984/local /grimwire/_design/local/_rewrite
> 'grimwire' design doc rewrites:
> [
> {
> "from": "",
> "to": "index.html",
> "method": "GET"
> },
> {
> "from": "*",
> "to": "*"
> }
> ]
> 'local' design doc rewrites:
> [
> {
> "from":"",
> "to":"index.html",
> "method":"GET"
> },
> {
> "from":"/posts",
> "to":"_list/wallpost/wallpost-by-created_at",
> "method":"GET"
> },
> {
> "from":"/posts",
> "to":"_update/wallpost",
> "method":"POST"
> },
> {
> "from":"/posts/:id",
> "to":"_show/wallpost/:id",
> "method":"GET"
> },
> {
> "from":"/posts/:id",
> "to":"_update/wallpost/:id",
> "method":"PUT"
> },
> {
> "from":"*",
> "to":"*"
> }
> ]
> Problem:
> The requests work as expected for some unknown period, then begin to respond
> with a 400 status and the "Exceeded rewrite recursion limit" error message.
> Changing the rewrites rules for both applications, including setting them to
> empty arrays, had no effect.
> The problem was solved by restarting the CouchDB service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Import Fauxton
+1 On 02/06/2013 01:50 PM, Jan Lehnardt wrote: Hey everybody, Fauxton, the reimplementation of Futon is coming along nicely and we’d like to wrap it into the CouchDB source tree, so we can start shipping a developer preview soon. And also to consolidate codebases and issue tracking and all that sort of stuff. As part of that we as dev@couchdb.apache.org need to vote on whether we like to import the suggested codebase. All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 If you have any questions, please speak up. You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). Everybody’s vote is going to count. Let’s make this a spectacular one! :) Here’s mine: +1 Best Jan
[jira] [Commented] (COUCHDB-1651) Server responds 400 "Exceeded rewrite recursion limit" indefinitely
[
https://issues.apache.org/jira/browse/COUCHDB-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573079#comment-13573079
]
Jeff Charette commented on COUCHDB-1651:
For what it is worth I started seeing this issue randomly when I pushed to
production on iriscouch.com. The only difference between the environments is
that I am running 1.2.0 locally and iriscouch is running 1.2.1. When this is
triggered it slowly consumes random links across my whole app.
Here are my rewrites:
{code:title=rewrites|borderStyle=solid}
module.exports = [
{from: '/menu/*', to: '../../../menu/*'},
{from: '/static/*', to: 'static/*'},
{from: '/img/*', to: '/static/img/*'},
{from: '/js/*', to: '/static/js/*'},
{from: '/css/*', to: '/static/css/*'},
{from: '/_*', to: '../../../_*'},
{from: '/modules.js', to: 'modules.js'},
{from: '/admin', to: '_show/form/create_doc'},
{from: '/query', to: '_list/query/by_type'},
{from: '/queryedit', to: '_list/queryedit/by_type'},
{from: '/edit/', to: '_list/edit/by_page', 'query':
{'include_docs':'true', 'id':'index'}},
{from: '/edit/:page', to: '_list/edit/by_page', 'query':
{'include_docs':'true', 'id':':page'}},
{from: '/', to: '_list/page/by_page', 'query': {'include_docs':'true',
'id':'index'}},
{from: '/:page', to: '_list/page/by_page', 'query':
{'include_docs':'true', 'id':':page'}}
];
{code}
> Server responds 400 "Exceeded rewrite recursion limit" indefinitely
> ---
>
> Key: COUCHDB-1651
> URL: https://issues.apache.org/jira/browse/COUCHDB-1651
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Reporter: Paul Frazee
>
> Running 1.2.1 on Windows 7 as a service.
> hosts file includes "127.0.0.1 grimwire.local"
> CouchDB conf includes vhosts entries:
> grimwire.local:5984/grimwire/_design/grimwire/_rewrite
> grimwire.local:5984/local /grimwire/_design/local/_rewrite
> 'grimwire' design doc rewrites:
> [
> {
> "from": "",
> "to": "index.html",
> "method": "GET"
> },
> {
> "from": "*",
> "to": "*"
> }
> ]
> 'local' design doc rewrites:
> [
> {
> "from":"",
> "to":"index.html",
> "method":"GET"
> },
> {
> "from":"/posts",
> "to":"_list/wallpost/wallpost-by-created_at",
> "method":"GET"
> },
> {
> "from":"/posts",
> "to":"_update/wallpost",
> "method":"POST"
> },
> {
> "from":"/posts/:id",
> "to":"_show/wallpost/:id",
> "method":"GET"
> },
> {
> "from":"/posts/:id",
> "to":"_update/wallpost/:id",
> "method":"PUT"
> },
> {
> "from":"*",
> "to":"*"
> }
> ]
> Problem:
> The requests work as expected for some unknown period, then begin to respond
> with a 400 status and the "Exceeded rewrite recursion limit" error message.
> Changing the rewrites rules for both applications, including setting them to
> empty arrays, had no effect.
> The problem was solved by restarting the CouchDB service.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Import Fauxton
On 6 February 2013 22:50, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) +1 I am so pleased to see everybody working on this! A+ Dave
Re: [VOTE] Import Fauxton
+1 On Feb 6, 2013, at 4:50 PM, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan > -- > >
Re: [VOTE] Import Fauxton
On Wed, Feb 6, 2013 at 2:33 PM, Ryan Ramage wrote: > +1.4 Not a valid vote :-P
Re: [VOTE] Import Fauxton
+1.4 On Wed, Feb 6, 2013 at 3:24 PM, Adam Kocoloski wrote: > +1 > > On Feb 6, 2013, at 5:00 PM, Paul Davis > wrote: > > > +1 > > > > On Wed, Feb 6, 2013 at 4:00 PM, Robert Newson > wrote: > >> +1 > >> > >> On 6 February 2013 21:58, Norman Barker > wrote: > >>> +1 > >>> > >>> On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace > >>> wrote: > +1 > > > On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca > wrote: > > > +1 > > > > > > On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson > wrote: > > > >> +1 > >> > >> > >> On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: > >> > >>> Hey everybody, > >>> > >>> Fauxton, the reimplementation of Futon is coming along nicely and > >>> we’d like to wrap it into the CouchDB source tree, so we can start > >>> shipping a developer preview soon. And also to consolidate > codebases > >>> and issue tracking and all that sort of stuff. > >>> > >>> As part of that we as dev@couchdb.apache.org (mailto: > >> dev@couchdb.apache.org) need to vote on whether > >>> we like to import the suggested codebase. > >>> > >>> All details should be on > >> https://issues.apache.org/jira/browse/COUCHDB-1664 > >>> > >>> If you have any questions, please speak up. > >>> > >>> You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > >>> > >>> Everybody’s vote is going to count. Let’s make this a spectacular > one! > > :) > >>> > >>> Here’s mine: > >>> > >>> +1 > >>> > >>> Best > >>> Jan > >>> -- > >> > >> > >> > >> > > > >
Re: [VOTE] Import Fauxton
+1 On Feb 6, 2013, at 5:00 PM, Paul Davis wrote: > +1 > > On Wed, Feb 6, 2013 at 4:00 PM, Robert Newson wrote: >> +1 >> >> On 6 February 2013 21:58, Norman Barker wrote: >>> +1 >>> >>> On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace >>> wrote: +1 On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: > +1 > > > On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: > >> +1 >> >> >> On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: >> >>> Hey everybody, >>> >>> Fauxton, the reimplementation of Futon is coming along nicely and >>> we’d like to wrap it into the CouchDB source tree, so we can start >>> shipping a developer preview soon. And also to consolidate codebases >>> and issue tracking and all that sort of stuff. >>> >>> As part of that we as dev@couchdb.apache.org (mailto: >> dev@couchdb.apache.org) need to vote on whether >>> we like to import the suggested codebase. >>> >>> All details should be on >> https://issues.apache.org/jira/browse/COUCHDB-1664 >>> >>> If you have any questions, please speak up. >>> >>> You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). >>> >>> Everybody’s vote is going to count. Let’s make this a spectacular one! > :) >>> >>> Here’s mine: >>> >>> +1 >>> >>> Best >>> Jan >>> -- >> >> >> >> >
Re: [VOTE] Import Fauxton
+1 On Feb 6, 2013, at 5:00 PM, Paul Davis wrote: > +1 > > On Wed, Feb 6, 2013 at 4:00 PM, Robert Newson wrote: >> +1 >> >> On 6 February 2013 21:58, Norman Barker wrote: >>> +1 >>> >>> On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace >>> wrote: +1 On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: > +1 > > > On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: > >> +1 >> >> >> On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: >> >>> Hey everybody, >>> >>> Fauxton, the reimplementation of Futon is coming along nicely and >>> we’d like to wrap it into the CouchDB source tree, so we can start >>> shipping a developer preview soon. And also to consolidate codebases >>> and issue tracking and all that sort of stuff. >>> >>> As part of that we as dev@couchdb.apache.org (mailto: >> dev@couchdb.apache.org) need to vote on whether >>> we like to import the suggested codebase. >>> >>> All details should be on >> https://issues.apache.org/jira/browse/COUCHDB-1664 >>> >>> If you have any questions, please speak up. >>> >>> You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). >>> >>> Everybody’s vote is going to count. Let’s make this a spectacular one! > :) >>> >>> Here’s mine: >>> >>> +1 >>> >>> Best >>> Jan >>> -- >> >> >> >> >
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 4:00 PM, Robert Newson wrote: > +1 > > On 6 February 2013 21:58, Norman Barker wrote: >> +1 >> >> On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace >> wrote: >>> +1 >>> >>> >>> On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: >>> +1 On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: > +1 > > > On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: > > > Hey everybody, > > > > Fauxton, the reimplementation of Futon is coming along nicely and > > we’d like to wrap it into the CouchDB source tree, so we can start > > shipping a developer preview soon. And also to consolidate codebases > > and issue tracking and all that sort of stuff. > > > > As part of that we as dev@couchdb.apache.org (mailto: > dev@couchdb.apache.org) need to vote on whether > > we like to import the suggested codebase. > > > > All details should be on > https://issues.apache.org/jira/browse/COUCHDB-1664 > > > > If you have any questions, please speak up. > > > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > > > Here’s mine: > > > > +1 > > > > Best > > Jan > > -- > > > >
[jira] [Resolved] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1654. --- Resolution: Fixed > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-1654. - > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Import Fauxton
+1 On 6 February 2013 21:58, Norman Barker wrote: > +1 > > On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace > wrote: >> +1 >> >> >> On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: >> >>> +1 >>> >>> >>> On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: >>> >>> > +1 >>> > >>> > >>> > On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: >>> > >>> > > Hey everybody, >>> > > >>> > > Fauxton, the reimplementation of Futon is coming along nicely and >>> > > we’d like to wrap it into the CouchDB source tree, so we can start >>> > > shipping a developer preview soon. And also to consolidate codebases >>> > > and issue tracking and all that sort of stuff. >>> > > >>> > > As part of that we as dev@couchdb.apache.org (mailto: >>> > dev@couchdb.apache.org) need to vote on whether >>> > > we like to import the suggested codebase. >>> > > >>> > > All details should be on >>> > https://issues.apache.org/jira/browse/COUCHDB-1664 >>> > > >>> > > If you have any questions, please speak up. >>> > > >>> > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). >>> > > >>> > > Everybody’s vote is going to count. Let’s make this a spectacular one! >>> :) >>> > > >>> > > Here’s mine: >>> > > >>> > > +1 >>> > > >>> > > Best >>> > > Jan >>> > > -- >>> > >>> > >>> > >>> > >>>
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572886#comment-13572886 ] ASF subversion and git services commented on COUCHDB-1654: -- Commit da35ed0f012c265d35a71cc12e3683bdaad9e6d3 in branch refs/heads/master from [~janl] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=da35ed0 ] COUCHDB-1654: Transparently update view signatures from <= 1.2.x. Updates 1.2.x or earlier view files to 1.3.x or later view files transparently, the first time the 1.2.x view file is opened by 1.3.x or later. Here's how it works: Before opening a view index, If no matching index file is found in the new location: calculate the <= 1.2.x view signature if a file with that signature lives in the old location copy it to the new location with the new signature in the name. Then proceed to open the view index as usual. After opening, read its header. If the header matches the <= 1.2.x style #index_header record: upgrade the header to the new #mrheader record The next time the view is used, the new header is used. If we crash after the rename, but before the header upgrade, the header upgrade is done on the next view opening. If we crash between upgrading to the new header and writing that header to disk, we start with the old header again, do the upgrade and write to disk. Includes etap tests in 250*.t. > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572885#comment-13572885 ] ASF subversion and git services commented on COUCHDB-1654: -- Commit 73195d31fcf192a4d821b0d751a4775f65753632 in branch refs/heads/1.3.x from [~janl] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=73195d3 ] COUCHDB-1654: Transparently update view signatures from <= 1.2.x. Updates 1.2.x or earlier view files to 1.3.x or later view files transparently, the first time the 1.2.x view file is opened by 1.3.x or later. Here's how it works: Before opening a view index, If no matching index file is found in the new location: calculate the <= 1.2.x view signature if a file with that signature lives in the old location copy it to the new location with the new signature in the name. Then proceed to open the view index as usual. After opening, read its header. If the header matches the <= 1.2.x style #index_header record: upgrade the header to the new #mrheader record The next time the view is used, the new header is used. If we crash after the rename, but before the header upgrade, the header upgrade is done on the next view opening. If we crash between upgrading to the new header and writing that header to disk, we start with the old header again, do the upgrade and write to disk. Includes etap tests in 250*.t. > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 2:55 PM, Michael Wallace wrote: > +1 > > > On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: > >> +1 >> >> >> On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: >> >> > +1 >> > >> > >> > On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: >> > >> > > Hey everybody, >> > > >> > > Fauxton, the reimplementation of Futon is coming along nicely and >> > > we’d like to wrap it into the CouchDB source tree, so we can start >> > > shipping a developer preview soon. And also to consolidate codebases >> > > and issue tracking and all that sort of stuff. >> > > >> > > As part of that we as dev@couchdb.apache.org (mailto: >> > dev@couchdb.apache.org) need to vote on whether >> > > we like to import the suggested codebase. >> > > >> > > All details should be on >> > https://issues.apache.org/jira/browse/COUCHDB-1664 >> > > >> > > If you have any questions, please speak up. >> > > >> > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). >> > > >> > > Everybody’s vote is going to count. Let’s make this a spectacular one! >> :) >> > > >> > > Here’s mine: >> > > >> > > +1 >> > > >> > > Best >> > > Jan >> > > -- >> > >> > >> > >> > >>
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 9:54 PM, Russell Branca wrote: > +1 > > > On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: > > > +1 > > > > > > On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: > > > > > Hey everybody, > > > > > > Fauxton, the reimplementation of Futon is coming along nicely and > > > we’d like to wrap it into the CouchDB source tree, so we can start > > > shipping a developer preview soon. And also to consolidate codebases > > > and issue tracking and all that sort of stuff. > > > > > > As part of that we as dev@couchdb.apache.org (mailto: > > dev@couchdb.apache.org) need to vote on whether > > > we like to import the suggested codebase. > > > > > > All details should be on > > https://issues.apache.org/jira/browse/COUCHDB-1664 > > > > > > If you have any questions, please speak up. > > > > > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > > > > > Everybody’s vote is going to count. Let’s make this a spectacular one! > :) > > > > > > Here’s mine: > > > > > > +1 > > > > > > Best > > > Jan > > > -- > > > > > > > > >
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 1:51 PM, Simon Metson wrote: > +1 > > > On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: > > > Hey everybody, > > > > Fauxton, the reimplementation of Futon is coming along nicely and > > we’d like to wrap it into the CouchDB source tree, so we can start > > shipping a developer preview soon. And also to consolidate codebases > > and issue tracking and all that sort of stuff. > > > > As part of that we as dev@couchdb.apache.org (mailto: > dev@couchdb.apache.org) need to vote on whether > > we like to import the suggested codebase. > > > > All details should be on > https://issues.apache.org/jira/browse/COUCHDB-1664 > > > > If you have any questions, please speak up. > > > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > > > Here’s mine: > > > > +1 > > > > Best > > Jan > > -- > > > >
Re: [VOTE] Import Fauxton
+1 On 02/06/2013 10:50 PM, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan
Re: [VOTE] Import Fauxton
+1 On Wednesday, 6 February 2013 at 21:50, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org (mailto:dev@couchdb.apache.org) > need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan > --
Re: [VOTE] Import Fauxton
+1 On Wed, Feb 6, 2013 at 10:50 PM, Jan Lehnardt wrote: > Hey everybody, > > Fauxton, the reimplementation of Futon is coming along nicely and > we’d like to wrap it into the CouchDB source tree, so we can start > shipping a developer preview soon. And also to consolidate codebases > and issue tracking and all that sort of stuff. > > As part of that we as dev@couchdb.apache.org need to vote on whether > we like to import the suggested codebase. > > All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 > > If you have any questions, please speak up. > > You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). > > Everybody’s vote is going to count. Let’s make this a spectacular one! :) > > Here’s mine: > > +1 > > Best > Jan > -- >
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572874#comment-13572874 ] Benoit Chesneau commented on COUCHDB-1654: -- +1 > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[IP Clearance] CouchDB: Fauxton
Dear Incubator, A number of non-committers offer a new admin interface to be submitted to CouchDB. The code is up on: git: https://github.com/cloudant-labs/couchdb/commits/fauxton (commit c31fa4bfb3448b04c9e5f27a656858e81d476e80) zip: http://people.apache.org/~jan/ip/couchdb-fauxton-c31fa4bfb3448b04c9e5f27a656858e81d476e80.zip sig: http://people.apache.org/~jan/ip/couchdb-fauxton-c31fa4bfb3448b04c9e5f27a656858e81d476e80.zip.sha (note, the zip includes the full CouchDB source again, since they’ve been working on a fork) The IP Clearance document: http://people.apache.org/~jan/ip/couchdb-fauxton.xml The Import Vote is ongoing and I will update the IP Clearance document accordingly, before committing. Thanks! Jan --
[VOTE] Import Fauxton
Hey everybody, Fauxton, the reimplementation of Futon is coming along nicely and we’d like to wrap it into the CouchDB source tree, so we can start shipping a developer preview soon. And also to consolidate codebases and issue tracking and all that sort of stuff. As part of that we as dev@couchdb.apache.org need to vote on whether we like to import the suggested codebase. All details should be on https://issues.apache.org/jira/browse/COUCHDB-1664 If you have any questions, please speak up. You can vote with a +1 (yay!), 0 (meh) or -1 (do not want). Everybody’s vote is going to count. Let’s make this a spectacular one! :) Here’s mine: +1 Best Jan --
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572872#comment-13572872 ] Robert Newson commented on COUCHDB-1654: +1 > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572868#comment-13572868 ] Jan Lehnardt commented on COUCHDB-1654: --- Thanks Randall! [~rnewson], can I get a +1 to merge this into 1.3.x? > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572861#comment-13572861 ] Randall Leeds commented on COUCHDB-1654: +1 -- Ship it! > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1664) Import Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572859#comment-13572859 ] Jan Lehnardt commented on COUCHDB-1664: --- A zipfile is provided at http://people.apache.org/~jan/ip/couchdb-fauxton-c31fa4bfb3448b04c9e5f27a656858e81d476e80.zip Signature: http://people.apache.org/~jan/ip/couchdb-fauxton-c31fa4bfb3448b04c9e5f27a656858e81d476e80.zip.sha > Import Fauxton > -- > > Key: COUCHDB-1664 > URL: https://issues.apache.org/jira/browse/COUCHDB-1664 > Project: CouchDB > Issue Type: Task > Components: Futon >Reporter: Jan Lehnardt > > Fauxton is the the next Futon. Now is a good time to get it’s code base into > Apache CouchDB. > The code currently lives at > https://github.com/cloudant-labs/couchdb/commits/fauxton > Here’s the sub-steps: > 1. ask the authors/committers to sign an Apache CLA (in progress) > 2. decide on how to integrate the code base (see below) > 3. decide if we want to keep calling it Fauxton, or just Futon again. > 4. fill out IP Clearance documentation (in progress). > 5. prepare the code base with legal requirements, like ASF headers & NOTICE. > I’ll volunteer to do champion all of these. > As for 2. Integration I propose the following: > - Ask INFRA for a separate repository couchdb-futon (or couchdb-fauxon as > per 3) > - in the CouchDB repo, make src/futon or wherever it should live a > git-submodule to the new couchdb-futon repo. > - Update build-from-checkout/clone instructions to add `git submodule update > --init` after `git clone ` > (I realise that not everyone likes submodules, I don’t exactly care about the > integration as long as it is a single command that needs to be run to make > things work. No solution is without drawbacks, so unless someone can point to > a point that makes submodules *not* work for this, I suggest we avoid this > particular bikeshed). > As for 3: Futon. > Once all that is in place we can work on integrating building Fauxton on > `make dist`. It should be a matter of installing the dependencies and calling > one command. For `make test` we should also run Fauxton’s test suite (when it > exists). None of that is critical for the import, though. > Consider this a draft. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1664) Import Fauxton
[ https://issues.apache.org/jira/browse/COUCHDB-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572856#comment-13572856 ] Jan Lehnardt commented on COUCHDB-1664: --- Latest commit hash for import: c31fa4bfb3448b04c9e5f27a656858e81d476e80 Shit’s getting real. > Import Fauxton > -- > > Key: COUCHDB-1664 > URL: https://issues.apache.org/jira/browse/COUCHDB-1664 > Project: CouchDB > Issue Type: Task > Components: Futon >Reporter: Jan Lehnardt > > Fauxton is the the next Futon. Now is a good time to get it’s code base into > Apache CouchDB. > The code currently lives at > https://github.com/cloudant-labs/couchdb/commits/fauxton > Here’s the sub-steps: > 1. ask the authors/committers to sign an Apache CLA (in progress) > 2. decide on how to integrate the code base (see below) > 3. decide if we want to keep calling it Fauxton, or just Futon again. > 4. fill out IP Clearance documentation (in progress). > 5. prepare the code base with legal requirements, like ASF headers & NOTICE. > I’ll volunteer to do champion all of these. > As for 2. Integration I propose the following: > - Ask INFRA for a separate repository couchdb-futon (or couchdb-fauxon as > per 3) > - in the CouchDB repo, make src/futon or wherever it should live a > git-submodule to the new couchdb-futon repo. > - Update build-from-checkout/clone instructions to add `git submodule update > --init` after `git clone ` > (I realise that not everyone likes submodules, I don’t exactly care about the > integration as long as it is a single command that needs to be run to make > things work. No solution is without drawbacks, so unless someone can point to > a point that makes submodules *not* work for this, I suggest we avoid this > particular bikeshed). > As for 3: Futon. > Once all that is in place we can work on integrating building Fauxton on > `make dist`. It should be a matter of installing the dependencies and calling > one command. For `make test` we should also run Fauxton’s test suite (when it > exists). None of that is critical for the import, though. > Consider this a draft. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572848#comment-13572848 ] Jan Lehnardt commented on COUCHDB-1654: --- Thanks Randall, all your assumptions are correct. The test case uses an actual 1.2.x-era view file. > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572845#comment-13572845 ] Randall Leeds commented on COUCHDB-1654: Hey, that looks pretty good to me! To make sure I understand, it seems like the fields used in signature calculation didn't really change, except that the record name changed which makes the first field of the record tuple different. Aside from that, it's just a matter of the location changing. The trick there is to calculate the index filename as though the module name were empty. Does that all sound right? Code looks fine. Have you tested it on any real views? > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1654) couchdb view sig changed
[ https://issues.apache.org/jira/browse/COUCHDB-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572817#comment-13572817 ] ASF subversion and git services commented on COUCHDB-1654: -- Commit 23cc54d54ed20efe01d3b9bfb294cadfca9f950b in branch refs/heads/1654-fix-view-signature-change from [~janl] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=23cc54d ] COUCHDB-1654: Transparently update view signatures from <= 1.2.x. Updates 1.2.x or earlier view files to 1.3.x or later view files transparently, the first time the 1.2.x view file is opened by 1.3.x or later. Here's how it works: Before opening a view index, If no matching index file is found in the new location: calculate the <= 1.2.x view signature if a file with that signature lives in the old location copy it to the new location with the new signature in the name. Then proceed to open the view index as usual. After opening, read its header. If the header matches the <= 1.2.x style #index_header record: upgrade the header to the new #mrheader record The next time the view is used, the new header is used. If we crash after the rename, but before the header upgrade, the header upgrade is done on the next view opening. If we crash between upgrading to the new header and writing that header to disk, we start with the old header again, do the upgrade and write to disk. Includes etap tests in 250*.t. > couchdb view sig changed > > > Key: COUCHDB-1654 > URL: https://issues.apache.org/jira/browse/COUCHDB-1654 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Robert Newson >Priority: Blocker > Fix For: 1.3 > > > view sigs and location changed between 1.2.x and 1.3.x, which would cause > full rebuilds. > to be clear: upgrading to 1.3 should not cause a view to rebuild from scratch. > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb > ➜ couchdb git:(1.3.x) find tmp > tmp > tmp/lib > tmp/lib/.db1_design > tmp/lib/.db1_design/0761939631be54bf36d3ed9172bcf689.view > tmp/lib/.db1_design/mrview > tmp/lib/.db1_design/mrview/641ce136c0f1dbe93aa94d3a419a0efe.view > tmp/lib/.delete > tmp/lib/_replicator.couch > tmp/lib/_users.couch > tmp/lib/db1.couch > tmp/log > tmp/log/couch.log > tmp/run > tmp/run/couch.uri > tmp/run/couchdb -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1667) Gracefully update from view_index_dir to index_dir
[ https://issues.apache.org/jira/browse/COUCHDB-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-1667. - > Gracefully update from view_index_dir to index_dir > -- > > Key: COUCHDB-1667 > URL: https://issues.apache.org/jira/browse/COUCHDB-1667 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Alexander Shorin >Priority: Blocker > Fix For: 1.3 > > Attachments: COUCHDB-1667.1-revert_to_view_index_dir.patch, > COUCHDB-1667.1-update_to_index_dir.patch > > > CouchDB 1.3 ships with new couch_index app[1] that uses `index_dir` config > option to locate directory to store view indexes. However, it replaces[2] old > `view_index_dir`option creating situation when recently updated default.ini > will have only `index_dir` option and old, but production used local.ini > would still have `view_index_dir`. There is a fallback[3], but there no > insurance that it will let user gracefully update. > This situation may leads to very bad situations, when all indexes will be > rebuilded against location that may not expects their on disk size (since > `view_index_dir` was pointed to the another mount point) which leads to > server fall. > [1]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=35e57870 > [2]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e83352f3 > [3]: > https://github.com/apache/couchdb/blob/master/src/couch_index/src/couch_index_util.erl#L22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1667) Gracefully update from view_index_dir to index_dir
[ https://issues.apache.org/jira/browse/COUCHDB-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt resolved COUCHDB-1667. --- Resolution: Fixed Fix Version/s: 1.3 > Gracefully update from view_index_dir to index_dir > -- > > Key: COUCHDB-1667 > URL: https://issues.apache.org/jira/browse/COUCHDB-1667 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Alexander Shorin >Priority: Blocker > Fix For: 1.3 > > Attachments: COUCHDB-1667.1-revert_to_view_index_dir.patch, > COUCHDB-1667.1-update_to_index_dir.patch > > > CouchDB 1.3 ships with new couch_index app[1] that uses `index_dir` config > option to locate directory to store view indexes. However, it replaces[2] old > `view_index_dir`option creating situation when recently updated default.ini > will have only `index_dir` option and old, but production used local.ini > would still have `view_index_dir`. There is a fallback[3], but there no > insurance that it will let user gracefully update. > This situation may leads to very bad situations, when all indexes will be > rebuilded against location that may not expects their on disk size (since > `view_index_dir` was pointed to the another mount point) which leads to > server fall. > [1]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=35e57870 > [2]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e83352f3 > [3]: > https://github.com/apache/couchdb/blob/master/src/couch_index/src/couch_index_util.erl#L22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1667) Gracefully update from view_index_dir to index_dir
[ https://issues.apache.org/jira/browse/COUCHDB-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572807#comment-13572807 ] ASF subversion and git services commented on COUCHDB-1667: -- Commit b267a29011c02712860dd69bd0b680e93739935b in branch refs/heads/master from [~janl] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=b267a29 ] COUCHDB-1667: Revert index_dir to view_index_dir config option. Patch by Alexander Shorin. > Gracefully update from view_index_dir to index_dir > -- > > Key: COUCHDB-1667 > URL: https://issues.apache.org/jira/browse/COUCHDB-1667 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Alexander Shorin >Priority: Blocker > Attachments: COUCHDB-1667.1-revert_to_view_index_dir.patch, > COUCHDB-1667.1-update_to_index_dir.patch > > > CouchDB 1.3 ships with new couch_index app[1] that uses `index_dir` config > option to locate directory to store view indexes. However, it replaces[2] old > `view_index_dir`option creating situation when recently updated default.ini > will have only `index_dir` option and old, but production used local.ini > would still have `view_index_dir`. There is a fallback[3], but there no > insurance that it will let user gracefully update. > This situation may leads to very bad situations, when all indexes will be > rebuilded against location that may not expects their on disk size (since > `view_index_dir` was pointed to the another mount point) which leads to > server fall. > [1]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=35e57870 > [2]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e83352f3 > [3]: > https://github.com/apache/couchdb/blob/master/src/couch_index/src/couch_index_util.erl#L22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1667) Gracefully update from view_index_dir to index_dir
[ https://issues.apache.org/jira/browse/COUCHDB-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572806#comment-13572806 ] ASF subversion and git services commented on COUCHDB-1667: -- Commit 824abd362aaef0f9893876d9adc23047c6e4d7eb in branch refs/heads/1.3.x from [~janl] [ https://git-wip-us.apache.org/repos/asf?p=couchdb.git;h=824abd3 ] COUCHDB-1667: Revert index_dir to view_index_dir config option. Patch by Alexander Shorin. > Gracefully update from view_index_dir to index_dir > -- > > Key: COUCHDB-1667 > URL: https://issues.apache.org/jira/browse/COUCHDB-1667 > Project: CouchDB > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Alexander Shorin >Priority: Blocker > Attachments: COUCHDB-1667.1-revert_to_view_index_dir.patch, > COUCHDB-1667.1-update_to_index_dir.patch > > > CouchDB 1.3 ships with new couch_index app[1] that uses `index_dir` config > option to locate directory to store view indexes. However, it replaces[2] old > `view_index_dir`option creating situation when recently updated default.ini > will have only `index_dir` option and old, but production used local.ini > would still have `view_index_dir`. There is a fallback[3], but there no > insurance that it will let user gracefully update. > This situation may leads to very bad situations, when all indexes will be > rebuilded against location that may not expects their on disk size (since > `view_index_dir` was pointed to the another mount point) which leads to > server fall. > [1]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=35e57870 > [2]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e83352f3 > [3]: > https://github.com/apache/couchdb/blob/master/src/couch_index/src/couch_index_util.erl#L22 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Summary of IRC meeting in #couchdb-meeting, Wed Feb 6 20:09:59 2013
Thanks all for participating! * * * The next meeting is on Wednesday, February 13th, 2013, 2pm GMT. Note the timezone change (6 hours earlier) to accommodate other time zones. Cheers Jan -- On Feb 6, 2013, at 21:35 , ASF IRC Services wrote: > Members present: jsonified, tilgovi, Jarda, jan, kocolosk, chewbranca, > Wohali > > > Meeting summary: > > > 1. Preface > > 2. 1.3.0 > a. Wohali to round out COUCHDB-523 (jan, 2) > b. Jan to solicit review for COUCHDB-1654 (jan, 2) > > 3. Fauxton > a. Fauxton getting ready to be submitted to the ASF (jan, 3) > > 4. AOB > a. Next meeting is on the same date, but 6 hours earlier (jan, 4) > > > > Actions: > > - Wohali to round out COUCHDB-523 (jan, 20:15:52) > - Jan to solicit review for COUCHDB-1654 (jan, 20:18:14) > > IRC log follows: > > > # 1. Preface # > > > # 2. 1.3.0 # > 20:11:44 [jan]: quick report for me: the only outstanding issues so far > are COUCHDB-1654 and COUCHDB-1667 > 20:11:52 [jan]: I plan to commit 1667 after the meeting > 20:12:22 [jan]: 1654 needs review by view server savy people. I’d like to > get at least a pair of eyes form benoitc kocolosk or davisp on here. Haven’t > heard anything yet > 20:12:38 [jan]: it looks farily complete to me, so I think we can start > shipping 1.3.0 after that. > 20:12:45 [jan]: anyone anything to add for 1.3.0? > 20:13:29 [jan]: ACTION plays jeopardy music > 20:13:37 [kocolosk]: thanks a bunch for hacking on that jan > 20:13:37 [chewbranca]: SHIP IT > 20:13:44 [jsonified]: any documenty stuff needed? > 20:13:44 [kocolosk]: it's been a very busy week for me > 20:13:52 [kocolosk]: i haven't forgotten about it > 20:13:59 [Wohali]: jan: > 20:13:59 [Wohali]: oops > 20:13:59 [jan]: kocolosk: my pleasure, I learned a lot. > 20:14:07 [Wohali]: jan: i still have that thing to port back but it > doesn't have to be in 1.3.0 > 20:14:07 [jan]: eager to get it reviewed though :) > 20:14:14 [chewbranca]: let me know if there is anything in need of testing on > 1.3 > 20:14:29 [kocolosk]: understood > 20:14:29 [Wohali]: COUCHDB-523 > 20:14:53 [jan]: Wohali: ah check > 20:14:59 [jan]: I wasn’t entirely accurate > 20:15:07 [Wohali]: i'll try > 20:15:07 [Wohali]: rephrase > 20:15:14 [Wohali]: i will make time for it this week :) > 20:15:15 [jan]: there are is also 1313 that rnewson wanted to do, but we > can bump that easily > 20:15:37 [jan]: > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%221.3%22%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > 20:15:44 [jan]: Wohali: cool, thanks > 20:15:52 [jan]: #action Wohali to round out COUCHDB-523 > 20:16:01 [jan]: chewbranca: all the testing, any time, installs, updates, > performance. > 20:16:37 [chewbranca]: jan: sounds good > 20:17:17 [jsonified]: http://s.apache.org/couchdb_130_blockers > 20:18:14 [jan]: #action Jan to solicit review for COUCHDB-1654 > 20:18:22 [jan]: ok, anything else on 1.3.0? > 20:18:52 [jan]: cool. > > > # 3. Fauxton # > 20:19:59 [jan]: chewbranca: all yours > 20:20:08 [jsonified]: > http://4.bp.blogspot.com/_dzrQ6Ausx9c/THFjFSgnSVI/C2A/r5hBra1Cm2I/s640/Tall+Ship+2+in+Forefront.jpg > 20:20:22 [Wohali]: that's a big ship > 20:20:30 [chewbranca]: fauxton is coming along, licenses added for most > everything, will update the NOTICE file tonight > 20:20:40 [chewbranca]: and have a few last 3rd party libs to check the > license on > 20:20:45 [chewbranca]: but should be good to go soon > 20:21:07 [chewbranca]: also of interest, I pushed out the functional UI of > the new view editor yesterday if anyone wants to check that out > 20:21:22 [jan]: #info Fauxton getting ready to be submitted to the ASF > 20:21:37 [chewbranca]: those were the two big status updates > 20:22:14 [jan]: cool > 20:22:22 [jan]: Jarda: any specific questions for fauxton > 20:22:52 [Jarda]: jan: regarding the issue tracking and repository etc > 20:22:53 [jan]: tilgovi: ohai, we’re just covering fauxton, and did 1.3.0 > before. if you want to hook in, after the fauxton topic it is AOB > 20:23:48 [Jarda]: jan: but I guess the license update already told most > of it > 20:23:49 [tilgovi]: oh, neat. I thought it was the other time today. > 20:23:54 [tilgovi]: glad to stumble in > 20:23:57 [jan]: Jarda: it is going to be in the CouchDB source tree > proper. Issues can go into CouchDB JIRA, or > https://github.com/apache/couchdb/pulls > 20:24:24 [jan]: Jarda: you won’t need to be able to BUILD CouchDB to work > on Fauxton though, we ship with a proxy feature that lets you work against, > say IrisCouch > 20:24:39 [Jarda]: jan: yeah I have the dev env up and running > 20:24:54 [jan]: coolio! > 20:25:02 [Jarda]: just would like to see a proper roadmap with issues or such > 20:2
Summary of IRC meeting in #couchdb-meeting, Wed Feb 6 20:09:59 2013
Members present: jsonified, tilgovi, Jarda, jan, kocolosk, chewbranca, Wohali Meeting summary: 1. Preface 2. 1.3.0 a. Wohali to round out COUCHDB-523 (jan, 2) b. Jan to solicit review for COUCHDB-1654 (jan, 2) 3. Fauxton a. Fauxton getting ready to be submitted to the ASF (jan, 3) 4. AOB a. Next meeting is on the same date, but 6 hours earlier (jan, 4) Actions: - Wohali to round out COUCHDB-523 (jan, 20:15:52) - Jan to solicit review for COUCHDB-1654 (jan, 20:18:14) IRC log follows: # 1. Preface # # 2. 1.3.0 # 20:11:44 [jan]: quick report for me: the only outstanding issues so far are COUCHDB-1654 and COUCHDB-1667 20:11:52 [jan]: I plan to commit 1667 after the meeting 20:12:22 [jan]: 1654 needs review by view server savy people. Iâd like to get at least a pair of eyes form benoitc kocolosk or davisp on here. Havenât heard anything yet 20:12:38 [jan]: it looks farily complete to me, so I think we can start shipping 1.3.0 after that. 20:12:45 [jan]: anyone anything to add for 1.3.0? 20:13:29 [jan]: ACTION plays jeopardy music 20:13:37 [kocolosk]: thanks a bunch for hacking on that jan 20:13:37 [chewbranca]: SHIP IT 20:13:44 [jsonified]: any documenty stuff needed? 20:13:44 [kocolosk]: it's been a very busy week for me 20:13:52 [kocolosk]: i haven't forgotten about it 20:13:59 [Wohali]: jan: 20:13:59 [Wohali]: oops 20:13:59 [jan]: kocolosk: my pleasure, I learned a lot. 20:14:07 [Wohali]: jan: i still have that thing to port back but it doesn't have to be in 1.3.0 20:14:07 [jan]: eager to get it reviewed though :) 20:14:14 [chewbranca]: let me know if there is anything in need of testing on 1.3 20:14:29 [kocolosk]: understood 20:14:29 [Wohali]: COUCHDB-523 20:14:53 [jan]: Wohali: ah check 20:14:59 [jan]: I wasnât entirely accurate 20:15:07 [Wohali]: i'll try 20:15:07 [Wohali]: rephrase 20:15:14 [Wohali]: i will make time for it this week :) 20:15:15 [jan]: there are is also 1313 that rnewson wanted to do, but we can bump that easily 20:15:37 [jan]: https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%221.3%22%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC 20:15:44 [jan]: Wohali: cool, thanks 20:15:52 [jan]: #action Wohali to round out COUCHDB-523 20:16:01 [jan]: chewbranca: all the testing, any time, installs, updates, performance. 20:16:37 [chewbranca]: jan: sounds good 20:17:17 [jsonified]: http://s.apache.org/couchdb_130_blockers 20:18:14 [jan]: #action Jan to solicit review for COUCHDB-1654 20:18:22 [jan]: ok, anything else on 1.3.0? 20:18:52 [jan]: cool. # 3. Fauxton # 20:19:59 [jan]: chewbranca: all yours 20:20:08 [jsonified]: http://4.bp.blogspot.com/_dzrQ6Ausx9c/THFjFSgnSVI/C2A/r5hBra1Cm2I/s640/Tall+Ship+2+in+Forefront.jpg 20:20:22 [Wohali]: that's a big ship 20:20:30 [chewbranca]: fauxton is coming along, licenses added for most everything, will update the NOTICE file tonight 20:20:40 [chewbranca]: and have a few last 3rd party libs to check the license on 20:20:45 [chewbranca]: but should be good to go soon 20:21:07 [chewbranca]: also of interest, I pushed out the functional UI of the new view editor yesterday if anyone wants to check that out 20:21:22 [jan]: #info Fauxton getting ready to be submitted to the ASF 20:21:37 [chewbranca]: those were the two big status updates 20:22:14 [jan]: cool 20:22:22 [jan]: Jarda: any specific questions for fauxton 20:22:52 [Jarda]: jan: regarding the issue tracking and repository etc 20:22:53 [jan]: tilgovi: ohai, weâre just covering fauxton, and did 1.3.0 before. if you want to hook in, after the fauxton topic it is AOB 20:23:48 [Jarda]: jan: but I guess the license update already told most of it 20:23:49 [tilgovi]: oh, neat. I thought it was the other time today. 20:23:54 [tilgovi]: glad to stumble in 20:23:57 [jan]: Jarda: it is going to be in the CouchDB source tree proper. Issues can go into CouchDB JIRA, or https://github.com/apache/couchdb/pulls 20:24:24 [jan]: Jarda: you wonât need to be able to BUILD CouchDB to work on Fauxton though, we ship with a proxy feature that lets you work against, say IrisCouch 20:24:39 [Jarda]: jan: yeah I have the dev env up and running 20:24:54 [jan]: coolio! 20:25:02 [Jarda]: just would like to see a proper roadmap with issues or such 20:25:09 [jan]: any more fauxton business? 20:25:30 [jan]: Jarda: gotta refer you to chewbranca, but I believe there is a collection somewhere 20:25:30 [Jarda]: to better get a grip of what needs to be done (well at the look of it, a lot) 20:25:52 [jan]: understood 20:26:07 [chewbranca]: current rough todo list is https://github.com/cloudant-labs/couchdb/blob/fauxton/src/fauxton/TODO.md 20:27:22 [jan]: woot 20:28:07 [jan]: okay, anything
[jira] [Commented] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
[ https://issues.apache.org/jira/browse/COUCHDB-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572655#comment-13572655 ] Jens Alfke commented on COUCHDB-1670: - > since is opaque. You have to pass back exactly what you got from couchdb. I don't think that's a reasonable expectation. The JSON is going to be transformed anyway (to insert the _rev), so at some point it's going to be translated into an internal format and then regenerated. The output has to be an equivalent JSON document, but that doesn't mean byte-for-byte equivalence. For instance, object keys could be in a different order, Unicode escapes could be turned into literals or vice versa, and numbers might be represented differently, like changing to/from scientific notation or suppressing trailing zeros after the decimal point. > Replicator crashes if numbers in checkpoint docs are expressed in scientific > notation > - > > Key: COUCHDB-1670 > URL: https://issues.apache.org/jira/browse/COUCHDB-1670 > Project: CouchDB > Issue Type: Bug > Components: Replication >Reporter: Jens Alfke > > The CouchDB 1.2 replicator process crashes with an Erlang exception when > parsing a checkpoint document read back from a remote database, if numbers in > the document were JSON-encoded in scientific notation instead of as integers. > This includes the properties source_last_seq, end_last_seq, start_last_seq. > That is, the following encoding works fine: > ..., "source_last_seq": 1234567, ... > whereas this completely-equivalent encoding causes an exception: > ..., "source_last_seq": 1.234567e+06, ... > This issue raised its head as a result of a CouchDB-compatible engine I'm > writing (the Couchbase Sync Gateway) which can serve as a passive replication > endpoint. It's implemented in Go, and the Go JSON package has the side effect > of (a) parsing all JSON numbers into type 'double', and (b) encoding all > doubles into JSON using scientific notation if they're more than six digits > long. The net effect is that when CouchDB stores a checkpoint into the Sync > Adapter's database and then later reads it back, it barfs due to the > scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
[ https://issues.apache.org/jira/browse/COUCHDB-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572643#comment-13572643 ] Robert Newson commented on COUCHDB-1670: That's an interesting one, however I think we should hold fast to the rule that since is opaque. You have to pass back exactly what you got from couchdb. That said, we should make this a tidier 400 Bad Request. > Replicator crashes if numbers in checkpoint docs are expressed in scientific > notation > - > > Key: COUCHDB-1670 > URL: https://issues.apache.org/jira/browse/COUCHDB-1670 > Project: CouchDB > Issue Type: Bug > Components: Replication >Reporter: Jens Alfke > > The CouchDB 1.2 replicator process crashes with an Erlang exception when > parsing a checkpoint document read back from a remote database, if numbers in > the document were JSON-encoded in scientific notation instead of as integers. > This includes the properties source_last_seq, end_last_seq, start_last_seq. > That is, the following encoding works fine: > ..., "source_last_seq": 1234567, ... > whereas this completely-equivalent encoding causes an exception: > ..., "source_last_seq": 1.234567e+06, ... > This issue raised its head as a result of a CouchDB-compatible engine I'm > writing (the Couchbase Sync Gateway) which can serve as a passive replication > endpoint. It's implemented in Go, and the Go JSON package has the side effect > of (a) parsing all JSON numbers into type 'double', and (b) encoding all > doubles into JSON using scientific notation if they're more than six digits > long. The net effect is that when CouchDB stores a checkpoint into the Sync > Adapter's database and then later reads it back, it barfs due to the > scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1670) Replicator crashes if numbers in checkpoint docs are expressed in scientific notation
Jens Alfke created COUCHDB-1670: --- Summary: Replicator crashes if numbers in checkpoint docs are expressed in scientific notation Key: COUCHDB-1670 URL: https://issues.apache.org/jira/browse/COUCHDB-1670 Project: CouchDB Issue Type: Bug Components: Replication Reporter: Jens Alfke The CouchDB 1.2 replicator process crashes with an Erlang exception when parsing a checkpoint document read back from a remote database, if numbers in the document were JSON-encoded in scientific notation instead of as integers. This includes the properties source_last_seq, end_last_seq, start_last_seq. That is, the following encoding works fine: ..., "source_last_seq": 1234567, ... whereas this completely-equivalent encoding causes an exception: ..., "source_last_seq": 1.234567e+06, ... This issue raised its head as a result of a CouchDB-compatible engine I'm writing (the Couchbase Sync Gateway) which can serve as a passive replication endpoint. It's implemented in Go, and the Go JSON package has the side effect of (a) parsing all JSON numbers into type 'double', and (b) encoding all doubles into JSON using scientific notation if they're more than six digits long. The net effect is that when CouchDB stores a checkpoint into the Sync Adapter's database and then later reads it back, it barfs due to the scientific notation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
