Re: rep_security merge to trunk
On 15 Mar 2009, at 04:35, Chris Anderson wrote: On Wed, Mar 11, 2009 at 4:51 PM, Damien Katz dam...@apache.org wrote: For importing existing docs, I think you could just use the all_or_nothing:true option and save the multiple copies of the same documents and they'll all be saved, and you don't have to worry about the _revisions stuff. I've posted a script that copies between two running CouchDB instances. I'm using the all_or_nothing option. It does attachments inline using base64 encoding because it mostly works. I think if you have attachments so big that they can't be buffered, you probably want to avoid bulk docs anyway. If anyone desperately needs such a script you might be able to convince me to modify what I've written. Blog post with script and instructions here: http://jchrisa.net/drl/_design/sofa/_show/post/Upgrading%20CouchDB%20databases%20to%20trunk Hi Chris, great work, thanks! Would it make sense to add the blog post script to the CouchDB wiki? I'd like to add a few notes and your blog is still read-only :) Cheers Jan --
Re: rep_security merge to trunk
On Sun, Mar 15, 2009 at 6:56 AM, Jeff Hinrichs - DMT dunde...@gmail.com wrote: On Sat, Mar 14, 2009 at 10:35 PM, Chris Anderson jch...@apache.org wrote: On Wed, Mar 11, 2009 at 4:51 PM, Damien Katz dam...@apache.org wrote: For importing existing docs, I think you could just use the all_or_nothing:true option and save the multiple copies of the same documents and they'll all be saved, and you don't have to worry about the _revisions stuff. I've posted a script that copies between two running CouchDB instances. I'm using the all_or_nothing option. It does attachments inline using base64 encoding because it mostly works. I think if you have attachments so big that they can't be buffered, you probably want to avoid bulk docs anyway. If anyone desperately needs such a script you might be able to convince me to modify what I've written. Blog post with script and instructions here: http://jchrisa.net/drl/_design/sofa/_show/post/Upgrading%20CouchDB%20databases%20to%20trunk Chris, Does this migrate conflicted documents or does it ignore them? yes, it migrates conflicts. It does document requests with GET /db/docid?open_revs=allattachments=true which gives a copy of each doc rev leaf node (that is the head rev and any conflict revs). Once I figured out that the same request works for conflicted and normal docs, the script got much simpler. Jan, what about blog comments? ;) -- Chris Anderson http://jchris.mfdz.com
Re: rep_security merge to trunk
On Sun, Mar 15, 2009 at 7:41 AM, Chris Anderson jch...@apache.org wrote: On Sun, Mar 15, 2009 at 6:56 AM, Jeff Hinrichs - DMT dunde...@gmail.com wrote: On Sat, Mar 14, 2009 at 10:35 PM, Chris Anderson jch...@apache.org wrote: On Wed, Mar 11, 2009 at 4:51 PM, Damien Katz dam...@apache.org wrote: For importing existing docs, I think you could just use the all_or_nothing:true option and save the multiple copies of the same documents and they'll all be saved, and you don't have to worry about the _revisions stuff. I've posted a script that copies between two running CouchDB instances. I'm using the all_or_nothing option. It does attachments inline using base64 encoding because it mostly works. I think if you have attachments so big that they can't be buffered, you probably want to avoid bulk docs anyway. If anyone desperately needs such a script you might be able to convince me to modify what I've written. Blog post with script and instructions here: http://jchrisa.net/drl/_design/sofa/_show/post/Upgrading%20CouchDB%20databases%20to%20trunk Chris, Does this migrate conflicted documents or does it ignore them? yes, it migrates conflicts. It does document requests with GET /db/docid?open_revs=allattachments=true which gives a copy of each doc rev leaf node (that is the head rev and any conflict revs). Once I figured out that the same request works for conflicted and normal docs, the script got much simpler. I forgot to mention that it just strips the _rev from the original documents, so in the case of conflicts the winning rev could change. If this is unacceptable for someone's application it should be possible to fix. -- Chris Anderson http://jchris.mfdz.com
Re: Bulk Docs
On Fri, Mar 13, 2009 at 11:03:30AM +1030, Antony Blakey wrote: On 13/03/2009, at 10:45 AM, Chris Anderson wrote: It seems like most of these problems just go away if you put all the data that needs to be edited transactionally into a single document. There is a tradeoff between document granularity and concurrency. Indeed, and a subheading under concurrency is ease of conflict resolution. I am tring to get around to writing up the simple and oft-quoted example of a replicated set of bookmarks. I don't think it's as simple as is claimed. If you keep all your bookmarks in one document it's easy as pie to program with, until you get a replication conflict, in which case couchdb gives you no help whatsoever. It just tells you that here are two different sets of bookmarks. People expect that a bookmark added on A will also be added on B, and a bookmark deleted on A will also be deleted on B. If you move to one-couchdb-object-per-bookmark then the replication becomes much easier to deal with. But then you have to deal with the relationships between documents - e.g. people expect their bookmarks to be ordered and nestable. Regards, Brian.
[jira] Updated: (COUCHDB-194) [startkey, endkey[: provide a right-open range selection method
[
https://issues.apache.org/jira/browse/COUCHDB-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson updated COUCHDB-194:
---
Fix Version/s: (was: 1.0)
0.9
Moved to 0.9 but we can push back if the API change is not a problem to have
later.
[startkey, endkey[: provide a right-open range selection method
---
Key: COUCHDB-194
URL: https://issues.apache.org/jira/browse/COUCHDB-194
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Affects Versions: 0.9
Reporter: Maximillian Dornseif
Priority: Blocker
Fix For: 0.9
While writing something about using CouchDB I came across the issue of slice
indexes (called startkey and endkey in CouchDB lingo).
I found no exact definition of startkey and endkey anywhere in the
documentation. Testing reveals that access on _all_docs and on views
documents are retuned in the interval
[startkey, endkey] = (startkey = k = endkey).
I don't know if this was a conscious design decision. But I like to promote a
slightly different interpretation (and thus API change):
[startkey, endkey[ = (startkey = k endkey).
Both approaches are valid and used in the real world. Ruby uses the inclusive
(right-closed in math speak) first approach:
l = [1,2,3,4]
l.slice(1,2)
= [2, 3]
Python uses the exclusive (right-open in math speak) second approach:
l = [1,2,3,4]
l[1,2]
[2]
For array indices both work fine and which one to prefer is mostly an issue
of habit. In spoken language both approaches are used: Have the Software
done until saturday probably means right-open to the client and right-closed
to the coder.
But if you are working with keys that are more than array indexes, then
right-open is much easier to handle. That is because you have to *guess* the
biggest value you want to get. The Wiki at
http://wiki.apache.org/couchdb/View_collation contains an example of that
problem:
It is suggested that you use
startkey=_design/endkey=_design/Z
or
startkey=_design/endkey=_design/\u″
to get a list of all design documents - also the replication system in the db
core uses the same hack.
This breaks if a design document is named ZTop or
\Iñtërnâtiônàlizætiøn. Such names might be unlikely but we are computer
scientists; unlikely is a bad approach to software engineering.
The think what we really want to ask CouchDB is to get all documents with
keys starting with '_design/'.
This is basically impossible to do with right-closed intervals. We could use
startkey=_design/endkey=_design0″ ('0′ is the ASCII character after '/')
and this will work fine ... until there is actually a document with the key
_design0″ in the system. Unlikely, but ...
To make selection by intervals reliable currently clients have to guess the
last key (the approach) or use the fist key not to include (the _design0
approach) and then post process the result to remove the last element
returned if it exactly matches the given endkey value.
If couchdb would change to a right-open interval approach post processing
would go away in most cases. See
http://blogs.23.nu/c0re/2008/12/building-a-track-and-trace-application-with-couchdb/
for two real world examples.
At least for string keys and float keys changing the meaning to [startkey,
endkey[ would allow selections like
* all strings starting with 'abc'
* all numbers between 10.5 and 11
It also would hopefully break not to much existing code. Since the notion of
endkey seems to be already considered fishy (see the Z approach) most
code seems to try to avoid that issue. For example
'startkey=_design/endkey=_design/Z' still would work unless you
have a design document being named exactly Z.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Bulk Docs
On Sun, Mar 15, 2009 at 4:55 PM, Brian Candler b.cand...@pobox.com wrote: On Fri, Mar 13, 2009 at 11:03:30AM +1030, Antony Blakey wrote: On 13/03/2009, at 10:45 AM, Chris Anderson wrote: It seems like most of these problems just go away if you put all the data that needs to be edited transactionally into a single document. There is a tradeoff between document granularity and concurrency. Indeed, and a subheading under concurrency is ease of conflict resolution. I am tring to get around to writing up the simple and oft-quoted example of a replicated set of bookmarks. I don't think it's as simple as is claimed. If you keep all your bookmarks in one document it's easy as pie to program with, until you get a replication conflict, in which case couchdb gives you no help whatsoever. It just tells you that here are two different sets of bookmarks. People expect that a bookmark added on A will also be added on B, and a bookmark deleted on A will also be deleted on B. If you move to one-couchdb-object-per-bookmark then the replication becomes much easier to deal with. But then you have to deal with the relationships between documents - e.g. people expect their bookmarks to be ordered and nestable. I don't think Chris was suggesting you put *all *bookmarks in a single document, just that the transactions themselves can be documents -- think ledger entry in double-entry accounting. In some circumstances you can use a reduce to roll these up into a useful view of your system state. The bookmarks case you mention is interesting -- and definitely common. The ordered list model is tough to accommodate, but you could always keep a doc that maintains this order state. Ordering operations should always occur distinctly from document change operations, so local consistency shouldn't be a problem. But I concede that this'll be damn tough to replicate. Another model -- the one I think Chris was hinting at -- would be to store the relevant properties of every rearrangement operation individually, and use a reduce (admittedly a very complex one) to get at the current ordering. I'm sure that given enough swings at implementation, certain patterns will emerge to make this kind of stuff a lot easier.
Re: Bulk Docs
On Sun, Mar 15, 2009 at 4:21 PM, Dean Landolt d...@deanlandolt.com wrote: The bookmarks case you mention is interesting -- and definitely common. The ordered list model is tough to accommodate, but you could always keep a doc that maintains this order state. Ordering operations should always occur distinctly from document change operations, so local consistency shouldn't be a problem. But I concede that this'll be damn tough to replicate. Damien once mentioned on IRC a clever way to do ordered lists. Keep each item in it's own document, and store the list position as a float. To insert an item between two others, average their position-floats and use that. In the case of replication with other items on the list from remote nodes, approximate order should be preserved. -- Chris Anderson http://jchris.mfdz.com
Re: Bulk Docs
On Sun, Mar 15, 2009 at 7:32 PM, Chris Anderson jch...@apache.org wrote: On Sun, Mar 15, 2009 at 4:21 PM, Dean Landolt d...@deanlandolt.com wrote: The bookmarks case you mention is interesting -- and definitely common. The ordered list model is tough to accommodate, but you could always keep a doc that maintains this order state. Ordering operations should always occur distinctly from document change operations, so local consistency shouldn't be a problem. But I concede that this'll be damn tough to replicate. Damien once mentioned on IRC a clever way to do ordered lists. Keep each item in it's own document, and store the list position as a float. To insert an item between two others, average their position-floats and use that. In the case of replication with other items on the list from remote nodes, approximate order should be preserved. Touché.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 4:58 PM, Chris Anderson jch...@apache.org wrote: We are within striking distance of 0.9 12 Outstanding issues: https://issues.apache.org:443/jira/secure/IssueNavigator.jspa?reset=truepid=12310780priority=1status=1status=4fixfor=12313208sorter/field=issuekeysorter/order=DESC I think it'd be very cool if we could release in time for ApacheCon EU - starts on March 23rd. I think this is feasible but it will require some doing. Some of these tickets may be as simple as documentation or exploration to see if the issue is resolved by the new replication security patch. None of them look very challenging. Chris -- Chris Anderson http://jchris.mfdz.com I figured I'd sit down and write out thoughts on the remaining bugs so we can have a jumping off point for what needs to be worked on. Here goes. * https://issues.apache.org:443/jira/browse/COUCHDB-34 Enable replicator to use HTTP authentication I'm guessing that this is affected by Damien's rep_security patch hitting trunk. Someone more familiar with that bit should check, but hopefully this one is as easy as already done. * https://issues.apache.org:443/jira/browse/COUCHDB-67 Allow unicode characters in database names. No patch provided. Chris Anderson added a link to one of Antony's github repositories that's got some code for this. If no one steps up and offers a patch on this one I would vote for pushing it to 0.10. * https://issues.apache.org:443/jira/browse/COUCHDB-128 couchdb is not starting properly from init.d script in trunk Patrick Antivackis reports problems with the -e flag on the shebang line for different platforms and makes a request for setting the user CouchDB runs as in the init.d script. No idea about the -e flag, but we should probably add the CouchDB username option if I'm not just missing it. * https://issues.apache.org:443/jira/browse/COUCHDB-135 Offset regression between 0.8.0 and trunk. There's a patch on JIRA for this one that's been confirmed to solve the issue. I'm waiting for Damien's feedback because he thought the btree modification was wrong. * https://issues.apache.org:443/jira/browse/COUCHDB-163 replicate attachments without Base64 encoding If I read my commit logs correctly, Adam comitted a patch that fixes this for one of the two replication directions. Not sure where things should go from here. * https://issues.apache.org:443/jira/browse/COUCHDB-169 POSIX shell incompatibilities Looks like Noah's got some notes about what needs to be done. I'm not at all certain what this would entail. * https://issues.apache.org:443/jira/browse/COUCHDB-172 Updating and deleting the same document with _bulk_docs There's a patch that shows that if you save a doc, and then make a _bulk_docs request with an edited version and a _deleted=True version a conflict is raised as would be expected. The original reporter hasn't confirmed or denied that the error still exists. * https://issues.apache.org:443/jira/browse/COUCHDB-178 $PREFIX/etc/default/couchdb not installed I can't say much other than that its installed on my system. I don't have enough autotools-fu to spot any errors looking through the various Makefile.am's * https://issues.apache.org:443/jira/browse/COUCHDB-183 No pagination in Futon for reduce views Looks like Jason Davies has got a couple patches up for this one. I haven't tried applying them but he's left a note saying that there's a todo item for blank pages at the beginning or end of the key range. I'd defer to Christopher Lenz on this one. * https://issues.apache.org:443/jira/browse/COUCHDB-185 group=true is silently dropped in non-reduce views There's a patch posted that has some consequences for Futon. Specifically, the first visit to a view page results in a full reduce (no group=true) being executed. I asked Christopher Lenz about this and things kinda got dropped there. Also of note is whether the error code for this should be a 500 or 400. I went with 500 because I treated it the same as any of the other view parameter errors (and it was easier to code :). There's also the case of group=truegroup_level=0 not being detected by this patch. * https://issues.apache.org:443/jira/browse/COUCHDB-194 [startkey, endkey[: provide a right-open range selection method There's no patch for this yet. I looked once and got confused on how to implement this for the start key. IIRC, the issue is that there is some weird interplay between the current options and how the inclusive might work. I'll take a closer look at this tonight and see if I can remember what was up with it. * https://issues.apache.org:443/jira/browse/COUCHDB-221 Test that validation and authorization work properly with replicated edits. Hopefully this is part of the rep_security patch and can just be closed as is. I'll defer to Adam and Damien for this one. * https://issues.apache.org:443/jira/browse/COUCHDB-223 Document a way to find out failed writes fro bulk requests and async writes I'm also going to
Re: 0.9 final sprint
Hi, great list Paul, thanks! :) On 16 Mar 2009, at 00:40, Paul Davis wrote: I figured I'd sit down and write out thoughts on the remaining bugs so we can have a jumping off point for what needs to be worked on. Here goes. [...] * https://issues.apache.org:443/jira/browse/COUCHDB-163 replicate attachments without Base64 encoding If I read my commit logs correctly, Adam comitted a patch that fixes this for one of the two replication directions. Not sure where things should go from here. Things are working a lot smoother already but Maximillian Dornseif reported a few remaining issues. My understanding is that he's talking to Adam in private because his database contains confidential information. I don't know the state of the ongoing work. * https://issues.apache.org:443/jira/browse/COUCHDB-185 group=true is silently dropped in non-reduce views There's a patch posted that has some consequences for Futon. Specifically, the first visit to a view page results in a full reduce (no group=true) being executed. I asked Christopher Lenz about this and things kinda got dropped there. Also of note is whether the error code for this should be a 500 or 400. I went with 500 because I treated it the same as any of the other view parameter errors (and it was easier to code :). There's also the case of group=truegroup_level=0 not being detected by this patch. An HTTP server should not deliberately send a 500 error message. A 500 response denotes all hope is lost when processing a request. If CouchDB can detect an invalid request is made, it should return a 400 status code. Cheers Jan --
Re: Bulk Docs
On 16/03/2009, at 10:02 AM, Chris Anderson wrote: Damien once mentioned on IRC a clever way to do ordered lists. Keep each item in it's own document, and store the list position as a float. To insert an item between two others, average their position-floats and use that. In the case of replication with other items on the list from remote nodes, approximate order should be preserved. I've user that technique in the past. The problem is that after a while you end up rounding off due to limited precision, and the user is left wondering why they can't change the order of their items. And you can't just renumber because that's begging the question. An alternative is to use ascii strings and rely on the fact that a am b, which allows infinite subdivision, although the problem then is that string length is unbounded, and then you need to consider the lifetime of the data and the insertion statistics, so it's not suitable for all ordering problems. I think it's obvious that any system such as this is going to require unbounded precision - which is what the string length represent. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The greatest challenge to any thinker is stating the problem in a way that will allow a solution -- Bertrand Russell
Re: Bulk Docs
On 16/03/2009, at 10:30 AM, Antony Blakey wrote: I've user that technique in the past. The problem is that after a while you end up rounding off due to limited precision, and the user is left wondering why they can't change the order of their items. And you can't just renumber because that's begging the question. An alternative is to use ascii strings and rely on the fact that a am b, which allows infinite subdivision, although the problem then is that string length is unbounded, and then you need to consider the lifetime of the data and the insertion statistics, so it's not suitable for all ordering problems. BTW, we did this to reduce the number of item needing to be touched when re-ordering pages in a CMS. IIRC the general solution is to treat (in abstract) the ordering of items as the in-order traversal of a binary tree. The brief form of the algorithm is to record in each item the path from the top e.g. 01 or 10 = termination, 00 = left, 11 = right. You then map that bit sequence, padded with 0, to an ascii form that preserves the ordering. Avoid unbounded lengths requires a balanced tree, which requires transactional support. It has the benefit of a low number of documents touched per update (in an amortized sense). Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson
Re: 0.9 final sprint
On Mar 15, 2009, at 7:56 PM, Jan Lehnardt wrote: * https://issues.apache.org:443/jira/browse/COUCHDB-163 replicate attachments without Base64 encoding If I read my commit logs correctly, Adam comitted a patch that fixes this for one of the two replication directions. Not sure where things should go from here. Things are working a lot smoother already but Maximillian Dornseif reported a few remaining issues. My understanding is that he's talking to Adam in private because his database contains confidential information. I don't know the state of the ongoing work. I haven't heard anything from Maximillian privately yet. Regarding attachments in push replication, I suppose it should be possible to upload attachments to the target server before sending the new document revisions. It would be cleaner if we could just do multipart requests, and Jan originally marked this one as a blocker because multipart was on the 0.9 roadmap. It's fine with me if we postpone further work on this ticket till after the 0.9 release. I don't have a whole lot of time to work on it at the moment. Best, Adam
[jira] Commented: (COUCHDB-128) couchdb is not starting properly from init.d script in trunk
[ https://issues.apache.org/jira/browse/COUCHDB-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682198#action_12682198 ] Noah Slater commented on COUCHDB-128: - The -e line should be POSIX compatible. Debian mandates the use of POSIX compatible shell scripts so that the shell can be changed from bash, sh, ash, or dash. If it is claimed that this is the case, I would like to see pointers to man pages detailing the problems. The CouchDB username is set from /etc/default/couchdb. Please check here. couchdb is not starting properly from init.d script in trunk Key: COUCHDB-128 URL: https://issues.apache.org/jira/browse/COUCHDB-128 Project: CouchDB Issue Type: Bug Components: Build System Reporter: Noah Slater Assignee: Noah Slater Priority: Blocker Fix For: 0.9 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-178) $PREFIX/etc/default/couchdb not installed
[ https://issues.apache.org/jira/browse/COUCHDB-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682199#action_12682199 ] Noah Slater commented on COUCHDB-178: - This works for me, can someone else confirm please, or I will close. Would like to see the output from make install included. $PREFIX/etc/default/couchdb not installed - Key: COUCHDB-178 URL: https://issues.apache.org/jira/browse/COUCHDB-178 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.9 Environment: Ubuntu 8.10 Reporter: Nolan Darilek Assignee: Noah Slater Priority: Blocker Fix For: 0.9 /usr/local/etc/default/couchdb isn't installed on a fresh checkout of trunk under Ubuntu 8.10. As a result, the default init script creates couchdb.stdout and couchdb.stderr files in the current directory when run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 07:40:54PM -0400, Paul Davis wrote: * https://issues.apache.org:443/jira/browse/COUCHDB-128 couchdb is not starting properly from init.d script in trunk Patrick Antivackis reports problems with the -e flag on the shebang line for different platforms and makes a request for setting the user CouchDB runs as in the init.d script. No idea about the -e flag, but we should probably add the CouchDB username option if I'm not just missing it. The -e line should be POSIX compatible. Debian mandates the use of POSIX compatible shell scripts so that the shell can be changed from bash, sh, ash, or dash. If it is claimed that this is the case, I would like to see pointers to man pages detailing the problems. The CouchDB username is set from /etc/default/couchdb. Please check here. I have added this to the ticket. * https://issues.apache.org:443/jira/browse/COUCHDB-169 POSIX shell incompatibilities Looks like Noah's got some notes about what needs to be done. I'm not at all certain what this would entail. Aye. * https://issues.apache.org:443/jira/browse/COUCHDB-178 $PREFIX/etc/default/couchdb not installed I can't say much other than that its installed on my system. I don't have enough autotools-fu to spot any errors looking through the various Makefile.am's This works for me, can someone else confirm please, or I will close. Would like to see the output from make install included. I have added this to the ticket. -- Noah Slater, http://tumbolia.org/nslater
Re: 0.9 final sprint
On Mon, Mar 16, 2009 at 12:56:49AM +0100, Jan Lehnardt wrote: An HTTP server should not deliberately send a 500 error message. A 500 response denotes all hope is lost when processing a request. If CouchDB can detect an invalid request is made, it should return a 400 status code. The 5xx line of errors indicate an actual internal error with CouchDB. If the client is in error, then the 4xx line of errors should be used. -- Noah Slater, http://tumbolia.org/nslater
[jira] Updated: (COUCHDB-178) $PREFIX/etc/default/couchdb not installed
[ https://issues.apache.org/jira/browse/COUCHDB-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Hinrichs updated COUCHDB-178: -- Attachment: output.txt as of couchdb - Apache CouchDB 0.9.0a752084 I am no longer experiencing this situation on Ubuntu 8.04 # etc/default/couchdb.tpl. Generated from couchdb.tpl.in by configure. # Sourced by init script for configuration. COUCHDB_USER=couchdb COUCHDB_INI_FILE=/usr/local/etc/couchdb/couch.ini COUCHDB_PID_FILE=/usr/local/var/run/couchdb.pid COUCHDB_STDOUT_FILE=/dev/null COUCHDB_STDERR_FILE=/dev/null COUCHDB_RESPAWN_TIMEOUT=5 However, on Ubuntu 8.10 /usr/local/etc/default/couchdb does not exist and couchdb.stdout / couchdb.stderr are created in what ever directory you issue the start/restart command from. I am including the output of sudo make install $PREFIX/etc/default/couchdb not installed - Key: COUCHDB-178 URL: https://issues.apache.org/jira/browse/COUCHDB-178 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.9 Environment: Ubuntu 8.10 Reporter: Nolan Darilek Assignee: Noah Slater Priority: Blocker Fix For: 0.9 Attachments: output.txt /usr/local/etc/default/couchdb isn't installed on a fresh checkout of trunk under Ubuntu 8.10. As a result, the default init script creates couchdb.stdout and couchdb.stderr files in the current directory when run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 8:16 PM, Jason Davies ja...@jasondavies.com wrote: Hi Paul, On 15 Mar 2009, at 23:40, Paul Davis wrote: * https://issues.apache.org:443/jira/browse/COUCHDB-183 No pagination in Futon for reduce views Looks like Jason Davies has got a couple patches up for this one. I haven't tried applying them but he's left a note saying that there's a todo item for blank pages at the beginning or end of the key range. I'd defer to Christopher Lenz on this one. Yep, I would recommend at least applying the patch as it stands (assuming cmlenz is happy with it) as it is extremely useful for anyone using reduce views in Futon. The only remaining issue is that you can't tell if you are at the end of the key range as reduce views don't return total_rows, hence it will just show zero rows if you carry on clicking Next Page (if descending=true is used this happens at the beginning instead of the end). The fix would be to fetch rows_per_page + 1 and check if returned_rows.length is less than this. Unless there are any objections to the above approach, I don't mind spending a bit of time tomorrow afternoon working up an updated patch so we can get this nailed. -- Jason Davies www.jasondavies.com I have a sever lack of JavaScript-Fu, but looking over it I don't see anything controversial. My thoughts would be to finish out the patch for the rows+1 to get it rounded out.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 9:41 PM, Adam Kocoloski kocol...@apache.org wrote: On Mar 15, 2009, at 7:56 PM, Jan Lehnardt wrote: * https://issues.apache.org:443/jira/browse/COUCHDB-163 replicate attachments without Base64 encoding If I read my commit logs correctly, Adam comitted a patch that fixes this for one of the two replication directions. Not sure where things should go from here. Things are working a lot smoother already but Maximillian Dornseif reported a few remaining issues. My understanding is that he's talking to Adam in private because his database contains confidential information. I don't know the state of the ongoing work. I haven't heard anything from Maximillian privately yet. Regarding attachments in push replication, I suppose it should be possible to upload attachments to the target server before sending the new document revisions. It would be cleaner if we could just do multipart requests, and Jan originally marked this one as a blocker because multipart was on the 0.9 roadmap. It's fine with me if we postpone further work on this ticket till after the 0.9 release. I don't have a whole lot of time to work on it at the moment. Best, Adam I would be +1 for delaying multipart replication requests till 0.10 because I assume that's going to be a bit of work. If we're looking to get 0.9 out soon then I don't see any reason not to call the current state of attachment replication good.
[jira] Updated: (COUCHDB-178) $PREFIX/etc/default/couchdb not installed
[ https://issues.apache.org/jira/browse/COUCHDB-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Joseph Davis updated COUCHDB-178: -- Attachment: config.log makeinstall.out After a clean install on Ubuntu 8.10 I am also experiencing no $PREFIX/etc/default action. I'm attaching both the config.log and `sudo make install` output for reference. $PREFIX/etc/default/couchdb not installed - Key: COUCHDB-178 URL: https://issues.apache.org/jira/browse/COUCHDB-178 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 0.9 Environment: Ubuntu 8.10 Reporter: Nolan Darilek Assignee: Noah Slater Priority: Blocker Fix For: 0.9 Attachments: config.log, makeinstall.out, output.txt /usr/local/etc/default/couchdb isn't installed on a fresh checkout of trunk under Ubuntu 8.10. As a result, the default init script creates couchdb.stdout and couchdb.stderr files in the current directory when run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 10:06 PM, Noah Slater nsla...@apache.org wrote: On Sun, Mar 15, 2009 at 07:40:54PM -0400, Paul Davis wrote: * https://issues.apache.org:443/jira/browse/COUCHDB-128 couchdb is not starting properly from init.d script in trunk Patrick Antivackis reports problems with the -e flag on the shebang line for different platforms and makes a request for setting the user CouchDB runs as in the init.d script. No idea about the -e flag, but we should probably add the CouchDB username option if I'm not just missing it. The -e line should be POSIX compatible. Debian mandates the use of POSIX compatible shell scripts so that the shell can be changed from bash, sh, ash, or dash. If it is claimed that this is the case, I would like to see pointers to man pages detailing the problems. The CouchDB username is set from /etc/default/couchdb. Please check here. I have added this to the ticket. * https://issues.apache.org:443/jira/browse/COUCHDB-169 POSIX shell incompatibilities Looks like Noah's got some notes about what needs to be done. I'm not at all certain what this would entail. Aye. * https://issues.apache.org:443/jira/browse/COUCHDB-178 $PREFIX/etc/default/couchdb not installed I can't say much other than that its installed on my system. I don't have enough autotools-fu to spot any errors looking through the various Makefile.am's This works for me, can someone else confirm please, or I will close. Would like to see the output from make install included. And so you shall have it. Looks like I'm not the only one though. For the record I did actually duplicate this. Weird. I have added this to the ticket. -- Noah Slater, http://tumbolia.org/nslater
[jira] Updated: (COUCHDB-290) Include sequence number in update notifications
[
https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliot Murphy updated COUCHDB-290:
--
Attachment: couchdb-sequences.patch
This is the patch that adds the sequence number to the update notification.
Output looks like this:
{type:updated,db:replication_notification_test,seq:1}
The seq : 1 part is what is added by this patch.
Include sequence number in update notifications
---
Key: COUCHDB-290
URL: https://issues.apache.org/jira/browse/COUCHDB-290
Project: CouchDB
Issue Type: Improvement
Affects Versions: 0.9
Reporter: Elliot Murphy
Priority: Minor
Fix For: 0.9
Attachments: couchdb-sequences.patch
Hi! There's been requests to include the sequence number when sending an
update notification. Thanks to the guidance from davisp on #couchdb on March
13th, I've been able to put together a little patch that does just that. In
the future I'm interested in doing the same for the create notification, and
perhaps extending create/delete/update notifications to include a list of
affected doc IDs.
For now though, just this simple patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 8:05 PM, Paul Davis paul.joseph.da...@gmail.com wrote: On Sun, Mar 15, 2009 at 10:08 PM, Noah Slater nsla...@apache.org wrote: On Mon, Mar 16, 2009 at 12:56:49AM +0100, Jan Lehnardt wrote: An HTTP server should not deliberately send a 500 error message. A 500 response denotes all hope is lost when processing a request. If CouchDB can detect an invalid request is made, it should return a 400 status code. The 5xx line of errors indicate an actual internal error with CouchDB. If the client is in error, then the 4xx line of errors should be used. -- Noah Slater, http://tumbolia.org/nslater I'm cool with making parameter errors a 400 response, but we should make sure to do this for all detectable errors then. At the moment the current code path is to throw an error which causes a 500 response. It should be a relatively easy swap though I'd like to hear preference for 0.9 or 0.10. I would probably lean towards 0.9 but I don't really mind either way. As of quite recently they are a 400 error. Woohoo! It should be easy to make the new ones 400 also by making them query_parse_errors -- Chris Anderson http://jchris.mfdz.com
Re: 0.9 final sprint
On Sun, Mar 15, 2009 at 11:57 PM, Chris Anderson jch...@apache.org wrote: On Sun, Mar 15, 2009 at 8:05 PM, Paul Davis paul.joseph.da...@gmail.com wrote: On Sun, Mar 15, 2009 at 10:08 PM, Noah Slater nsla...@apache.org wrote: On Mon, Mar 16, 2009 at 12:56:49AM +0100, Jan Lehnardt wrote: An HTTP server should not deliberately send a 500 error message. A 500 response denotes all hope is lost when processing a request. If CouchDB can detect an invalid request is made, it should return a 400 status code. The 5xx line of errors indicate an actual internal error with CouchDB. If the client is in error, then the 4xx line of errors should be used. -- Noah Slater, http://tumbolia.org/nslater I'm cool with making parameter errors a 400 response, but we should make sure to do this for all detectable errors then. At the moment the current code path is to throw an error which causes a 500 response. It should be a relatively easy swap though I'd like to hear preference for 0.9 or 0.10. I would probably lean towards 0.9 but I don't really mind either way. As of quite recently they are a 400 error. Woohoo! It should be easy to make the new ones 400 also by making them query_parse_errors -- Chris Anderson http://jchris.mfdz.com Awesome, that should make this even easier than I imagined.
