[jira] Created: (COUCHDB-638) extend docid in show
extend docid in show Key: COUCHDB-638 URL: https://issues.apache.org/jira/browse/COUCHDB-638 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.11, 0.12 Reporter: Benoit Chesneau Actually when you pass a docid to a show with slashes (encoded or not) it will stop at first part and return a 404. Ex : /db/_design/ddocname/_show/showname/docid/with/slashes or /db/_design/ddocname/_show/showname/docid%2Fwith%2slashes Each return 404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-638) extend docid in show
[ https://issues.apache.org/jira/browse/COUCHDB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-638: Issue Type: Bug (was: Improvement) extend docid in show Key: COUCHDB-638 URL: https://issues.apache.org/jira/browse/COUCHDB-638 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 0.11, 0.12 Reporter: Benoit Chesneau Actually when you pass a docid to a show with slashes (encoded or not) it will stop at first part and return a 404. Ex : /db/_design/ddocname/_show/showname/docid/with/slashes or /db/_design/ddocname/_show/showname/docid%2Fwith%2slashes Each return 404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-638) extend docid in show
[ https://issues.apache.org/jira/browse/COUCHDB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau closed COUCHDB-638. --- Resolution: Fixed fix commited revision 906423 http://svn.apache.org/viewvc?rev=906423view=rev extend docid in show Key: COUCHDB-638 URL: https://issues.apache.org/jira/browse/COUCHDB-638 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 0.11, 0.12 Reporter: Benoit Chesneau Actually when you pass a docid to a show with slashes (encoded or not) it will stop at first part and return a 404. Ex : /db/_design/ddocname/_show/showname/docid/with/slashes or /db/_design/ddocname/_show/showname/docid%2Fwith%2slashes Each return 404. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-589) Simplify Query Server interface and Design Handlers
[ https://issues.apache.org/jira/browse/COUCHDB-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829572#action_12829572 ] Benoit Chesneau commented on COUCHDB-589: - I'm all for having it back . Actually this is very needed for people who would like to create embedded application with clean url with the rewriter for example. if we can't catch the 404 in _show we have to wrap all shows in an html with urls in fragments or such if we don't want to display the 404 or provide some action. Maybe it could be an option in design doc ? : show_404 = true smth like it ? Simplify Query Server interface and Design Handlers --- Key: COUCHDB-589 URL: https://issues.apache.org/jira/browse/COUCHDB-589 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Chris Anderson Assignee: Chris Anderson Attachments: ddoc_qs.patch, design_handlers.patch This patch refactors list, show, update, filter, and view handling to have a unified interface for loading the design document and functions from it. It is a step on the path to removing a lot of function src passing overhead from the view server protocol. The patch also removes some old part of the API while improving other parts of the API. The big changes: Load the design document before handing it to the design document handlers. This removes a lot of duplicated code. Remove /db/_view handler. I think it's in our interest to remove the last bits of the old-style API before 0.11. I also clean up some rough edges in the API. I plan to commit this patch soon, but want to give people an opportunity to look it over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
On Wed, Feb 03, 2010 at 02:27:56PM -0800, Jan Lehnardt wrote: Sorry to be blunt, but do you have numbers to back that up? This smells very much of premature optimisation. Reading a document costs: 1 disk seek to the end of the db file to grab the b-tree root + n disk seeks to the document (n 5 to 10 in most cases) In a well cached database, most of the seeks are free, but the last one usually isn't (unless you can hold a full database in memory). That's not true here. If _readers were a document within the database then the *same* document would be read for every access, and therefore it would be cached. There's no seek. But again you've ignored my main point: I'm proposing that the authorisation be a role within the userctx, and the userctx is already loaded. Free is better than cheap. Actually, that's not entirely true. We want to have publicly-readable databases, so we need an _anon user with roles assigned to it, and the effective roles you get would be the union of the roles from your user record plus the roles from the _anon user. That might mean reading the _anon record from the _users database. That will always be the same record, so is bound to be cached. Regards, Brian.
[jira] Updated: (COUCHDB-589) Simplify Query Server interface and Design Handlers
[ https://issues.apache.org/jira/browse/COUCHDB-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-589: Attachment: show_handle.404.diff patch the put back 404 error handling in show.If ddoc member show_handle_404 is true, shows can catch 404 error, else CoucDB return 404 error. Simplify Query Server interface and Design Handlers --- Key: COUCHDB-589 URL: https://issues.apache.org/jira/browse/COUCHDB-589 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Chris Anderson Assignee: Chris Anderson Attachments: ddoc_qs.patch, design_handlers.patch, show_handle.404.diff This patch refactors list, show, update, filter, and view handling to have a unified interface for loading the design document and functions from it. It is a step on the path to removing a lot of function src passing overhead from the view server protocol. The patch also removes some old part of the API while improving other parts of the API. The big changes: Load the design document before handing it to the design document handlers. This removes a lot of duplicated code. Remove /db/_view handler. I think it's in our interest to remove the last bits of the old-style API before 0.11. I also clean up some rough edges in the API. I plan to commit this patch soon, but want to give people an opportunity to look it over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: associating UUIDs to DBs
On Feb 3, 2010, at 4:53 AM, Brian Candler wrote: On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote: If couchdb tracked replication by a Merkle tree, it would obsolete the update_seq mechanism? Only if you weren't doing filtered/selective replication. And probably only if there was nothing else different between the two databases (e.g. _local docs, _design docs, reader acls etc) Correct, Merkle trees are only useful if you expect the two databases to be completely identical. But Bob's right, I'm essentially proposing that our by_seq btree is extended into a full Merkle tree for this particular use-case. Adam
Re: associating UUIDs to DBs
On Thu, Feb 4, 2010 at 10:19 AM, Adam Kocoloski kocol...@apache.org wrote: On Feb 3, 2010, at 4:53 AM, Brian Candler wrote: On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote: If couchdb tracked replication by a Merkle tree, it would obsolete the update_seq mechanism? Only if you weren't doing filtered/selective replication. And probably only if there was nothing else different between the two databases (e.g. _local docs, _design docs, reader acls etc) Correct, Merkle trees are only useful if you expect the two databases to be completely identical. But Bob's right, I'm essentially proposing that our by_seq btree is extended into a full Merkle tree for this particular use-case. Adam Most intriguing. Could you expand on that a bit? Paul
CouchDB defaults
Hey guys, when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) It sure would make my life even easier. :D Thoughs? Till
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 17:06, till klimp...@gmail.com wrote: when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) With my Gentoo packaging hat on, +1. Also, COUCHDB_PID_FILE. Cheers, Dirkjan
Re: associating UUIDs to DBs
On Feb 4, 2010, at 10:44 AM, Paul Davis wrote: On Thu, Feb 4, 2010 at 10:19 AM, Adam Kocoloski kocol...@apache.org wrote: On Feb 3, 2010, at 4:53 AM, Brian Candler wrote: On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote: If couchdb tracked replication by a Merkle tree, it would obsolete the update_seq mechanism? Only if you weren't doing filtered/selective replication. And probably only if there was nothing else different between the two databases (e.g. _local docs, _design docs, reader acls etc) Correct, Merkle trees are only useful if you expect the two databases to be completely identical. But Bob's right, I'm essentially proposing that our by_seq btree is extended into a full Merkle tree for this particular use-case. Adam Most intriguing. Could you expand on that a bit? Paul Hi Paul, The more I think about it using by_seq may not be the optimal choice here. Consider the case where I snapshot my .couch file over to a new server, and in the meantime I update the document that was occupying update_seq 1 on the original. The analysis I proposed above would conclude that the replication needs to start from the beginning, which is true, but overlooks the fact that only one document has changed. An alternative would be to do the Merkle stuff in the by_id tree, and instead of identifying the last update_seq where two DBs are identical, identify the set of documents that differ between the two DBs. Replicate just those documents using Filipe's new patch, then record a checkpoint at the source's latest update_seq. You're now fully caught up in case you're planning any future _changes-based incremental replications. If we went ahead and implemented this I think the UUID becomes superfluous from the replicator's perspective. You wouldn't want to restrict this Merkle tree check to UUID-matched DBs, as it would be useful for reducing entropy in a sharded database cluster that stores multiple copies of each document in different database shards. In fact, IIRC that was a Dynamo feature in the original Amazon paper. Adam
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 5:10 PM, Dirkjan Ochtman djc.ocht...@gmail.com wrote: On Thu, Feb 4, 2010 at 17:06, till klimp...@gmail.com wrote: when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) With my Gentoo packaging hat on, +1. Also, COUCHDB_PID_FILE. +1 to that. ;) Till Cheers, Dirkjan
Re: CouchDB defaults
But aren't all those per-instance parameters? Why would you want them compiled into the binaries? - Matt On 4 February 2010 16:17, till klimp...@gmail.com wrote: On Thu, Feb 4, 2010 at 5:10 PM, Dirkjan Ochtman djc.ocht...@gmail.com wrote: On Thu, Feb 4, 2010 at 17:06, till klimp...@gmail.com wrote: when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) With my Gentoo packaging hat on, +1. Also, COUCHDB_PID_FILE. +1 to that. ;) Till Cheers, Dirkjan
Re: CouchDB defaults
Thoughts Noah? I don't immediately see anything wrong with this, but I don't know if other packager people have different expectations. On Thu, Feb 4, 2010 at 11:06 AM, till klimp...@gmail.com wrote: Hey guys, when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) It sure would make my life even easier. :D Thoughs? Till
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 5:51 PM, Paul Davis paul.joseph.da...@gmail.com wrote: Thoughts Noah? I don't immediately see anything wrong with this, but I don't know if other packager people have different expectations. Can't speak for everyone, but even when I roll a new port on freebsd, this would come in handy. ;) My ubuntu stuff is primarily me automating stuff on ec2 instances where as little manual configuration is key. And if this means a couple switches allow me to skip on post-processing my installs through another script, I'm game. :D Till
Re: CouchDB defaults
On 4 February 2010 16:56, till klimp...@gmail.com wrote: On Thu, Feb 4, 2010 at 5:49 PM, Matt Goodall matt.good...@gmail.com wrote: But aren't all those per-instance parameters? Why would you want them compiled into the binaries? - Matt No, I want to influence whatever is in defaults or whatever your system calls it. ;) People would still be able to edit defaults to make it fit to their setup, or if the setup ever changes, etc.. Ah, sorry. I interpreted your original email as configure switches as an alternative to defaults. Ignore me. - Matt
handling 404 errors in shows function
Since latest changes in view serverr, we can't handle 404 errors in show docs. Reason invoked by @jchris is that most of users won't have the use for it and it will raise 500 error in case they don't handle case where the doc doesn't exist. But this feature could be very useful in some cases : - wiki - doc redirection - ... The best advantage is that it allows us via the rewriter to have clean url and 404 handling without using ajax and pseudo urls via fragments and javascript. I've written a new version of couch.it that heavily use that. I'm all for it goes back. @jchris proposed to make it optional which sound fine. I've written a patch against latest trunk that exactly does that : https://issues.apache.org/jira/browse/COUCHDB-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel (where discussion started too). The patch test if show_handle_404 property in the design doc exists and is equal to true and only in this case allow shows function to manage 404. In all other cases, a 404 error is returned if the doc doesn't exist. Are you ok with this patch ? - benoît
Re: CouchDB defaults
I'm unsure. Would he accept a patch for ./configure that set default values in local.ini too? On 4 Feb 2010, at 16:51, Paul Davis wrote: Thoughts Noah? I don't immediately see anything wrong with this, but I don't know if other packager people have different expectations. On Thu, Feb 4, 2010 at 11:06 AM, till klimp...@gmail.com wrote: Hey guys, when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) It sure would make my life even easier. :D Thoughs? Till
Re: CouchDB defaults
Hey Noah, anything I can do to clear this up, or better explain what I (or well, we want)? Here's a rundown: ./configure --couchdb-user=root \ --couchdb-stdout-file=/my/log/file/for/stdout \ --couchdb-stderr-file=/my/log/file/for/stderr \ --couchdb-respawn-timeout=10 \ --couchdb-pidfile=/home/till/noah.pid ... essentially, this would populate /etc/defaults/couchdb. Till On Thu, Feb 4, 2010 at 7:30 PM, Noah Slater nsla...@tumbolia.org wrote: I'm unsure. Would he accept a patch for ./configure that set default values in local.ini too? On 4 Feb 2010, at 16:51, Paul Davis wrote: Thoughts Noah? I don't immediately see anything wrong with this, but I don't know if other packager people have different expectations. On Thu, Feb 4, 2010 at 11:06 AM, till klimp...@gmail.com wrote: Hey guys, when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) It sure would make my life even easier. :D Thoughs? Till
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 1:30 PM, Noah Slater nsla...@tumbolia.org wrote: I'm unsure. Would he accept a patch for ./configure that set default values in local.ini too? Theoretically, we sorta do this because it does get variable substitution from config settings.
Re: CouchDB defaults
Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? On 4 Feb 2010, at 19:05, till wrote: Hey Noah, anything I can do to clear this up, or better explain what I (or well, we want)? Here's a rundown: ./configure --couchdb-user=root \ --couchdb-stdout-file=/my/log/file/for/stdout \ --couchdb-stderr-file=/my/log/file/for/stderr \ --couchdb-respawn-timeout=10 \ --couchdb-pidfile=/home/till/noah.pid ... essentially, this would populate /etc/defaults/couchdb. Till On Thu, Feb 4, 2010 at 7:30 PM, Noah Slater nsla...@tumbolia.org wrote: I'm unsure. Would he accept a patch for ./configure that set default values in local.ini too? On 4 Feb 2010, at 16:51, Paul Davis wrote: Thoughts Noah? I don't immediately see anything wrong with this, but I don't know if other packager people have different expectations. On Thu, Feb 4, 2010 at 11:06 AM, till klimp...@gmail.com wrote: Hey guys, when I install couchdb e.g. on ubuntu, it creates a couple settings in /etc/default/couchdb. I was wondering what you guys think about adding ./configure switches for each one of them (COUCHDB_USER, COUCHDB_STDOUT_FILE, COUCHDB_STDERR_FILE, COUCHDB_RESPAWN_TIMEOUT)? =) It sure would make my life even easier. :D Thoughs? Till
[jira] Updated: (COUCHDB-589) Simplify Query Server interface and Design Handlers
[ https://issues.apache.org/jira/browse/COUCHDB-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-589: Attachment: show_handle.404-2.patch new version of the patch. Option is now in design doc 'options' property. Simplify Query Server interface and Design Handlers --- Key: COUCHDB-589 URL: https://issues.apache.org/jira/browse/COUCHDB-589 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Chris Anderson Assignee: Chris Anderson Attachments: ddoc_qs.patch, design_handlers.patch, show_handle.404-2.patch, show_handle.404.diff This patch refactors list, show, update, filter, and view handling to have a unified interface for loading the design document and functions from it. It is a step on the path to removing a lot of function src passing overhead from the view server protocol. The patch also removes some old part of the API while improving other parts of the API. The big changes: Load the design document before handing it to the design document handlers. This removes a lot of duplicated code. Remove /db/_view handler. I think it's in our interest to remove the last bits of the old-style API before 0.11. I also clean up some rough edges in the API. I plan to commit this patch soon, but want to give people an opportunity to look it over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 9:03 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? IMHO, there doesn't have to be a line drawn anywhere. If people request more options, why not provide them? Unless there's a good reason not to. These kind of switches make packing a lot easier and provide more flexibility to anyone who runs CouchDB from source. Take a look at ./configure --help from a MySQL source download, or Apache. Plenty of options to choose from. :) Till
Re: CouchDB defaults
On 4 Feb 2010, at 20:23, till wrote: On Thu, Feb 4, 2010 at 9:03 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? IMHO, there doesn't have to be a line drawn anywhere. If people request more options, why not provide them? Unless there's a good reason not to. Every additional option adds cognitive burden to: * Maintaining the configure.ac script * Understanding the output from ./configure --help So I would argue that we need to think about where to draw the line here. Note, I've not expressed an opinion either way whether this crosses whatever line may exist.
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 12:31, Noah Slater nsla...@tumbolia.org wrote: On 4 Feb 2010, at 20:23, till wrote: On Thu, Feb 4, 2010 at 9:03 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? It becomes tempting to draw the line when the number of options explode, so why not leave it at two? --with-defaults-file --with-local-ini Then we don't need to add more options as the defaults environment grows.
Re: CouchDB defaults
Nope, I don't think i like this. The location of the file should be standard. On 4 Feb 2010, at 20:50, Randall Leeds wrote: On Thu, Feb 4, 2010 at 12:31, Noah Slater nsla...@tumbolia.org wrote: On 4 Feb 2010, at 20:23, till wrote: On Thu, Feb 4, 2010 at 9:03 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? It becomes tempting to draw the line when the number of options explode, so why not leave it at two? --with-defaults-file --with-local-ini Then we don't need to add more options as the defaults environment grows.
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 4:30 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I don't think i like this. The location of the file should be standard. On 4 Feb 2010, at 20:50, Randall Leeds wrote: On Thu, Feb 4, 2010 at 12:31, Noah Slater nsla...@tumbolia.org wrote: On 4 Feb 2010, at 20:23, till wrote: On Thu, Feb 4, 2010 at 9:03 PM, Noah Slater nsla...@tumbolia.org wrote: Nope, I understand what you want, I just don't know if it's a good idea. So my thought experiment was to wonder if we'd do the same for the other configuration files. As in, where is the line drawn? It becomes tempting to draw the line when the number of options explode, so why not leave it at two? --with-defaults-file --with-local-ini Then we don't need to add more options as the defaults environment grows. I think he means copy the file specified by --with-defaults-file to the standard location.
Re: CouchDB defaults
On Thu, Feb 4, 2010 at 13:37, Paul Davis paul.joseph.da...@gmail.com wrote: I think he means copy the file specified by --with-defaults-file to the standard location. Yes.
Re: associating UUIDs to DBs
On Thu, Feb 4, 2010 at 08:17, Adam Kocoloski kocol...@apache.org wrote: If we went ahead and implemented this I think the UUID becomes superfluous from the replicator's perspective. You wouldn't want to restrict this Merkle tree check to UUID-matched DBs, as it would be useful for reducing entropy in a sharded database cluster that stores multiple copies of each document in different database shards. In fact, IIRC that was a Dynamo feature in the original Amazon paper. I mostly follow and I think I agree. Can you clarify as it would be useful for reducing entropy...? Randall
Re: associating UUIDs to DBs
On Feb 4, 2010, at 5:05 PM, Randall Leeds wrote: On Thu, Feb 4, 2010 at 08:17, Adam Kocoloski kocol...@apache.org wrote: If we went ahead and implemented this I think the UUID becomes superfluous from the replicator's perspective. You wouldn't want to restrict this Merkle tree check to UUID-matched DBs, as it would be useful for reducing entropy in a sharded database cluster that stores multiple copies of each document in different database shards. In fact, IIRC that was a Dynamo feature in the original Amazon paper. I mostly follow and I think I agree. Can you clarify as it would be useful for reducing entropy...? Randall Sure, that was too terse on my part. I'm referring to the case where you're promising to write N copies of a document in your cluster, but for whatever reason you only succeed WN times. Hence entropy -- the N shards start diverging from one another after transient failures. You want those missing writes to eventually propagate to the N-W shards that didn't get them. CouchDB's _changes replication works for this purpose, but it's relatively resource-intensive because it checks for the existence of every update on the target. I suspect that comparing Merkle trees may be a more efficient way to figure out what to replicate in this special case where the two DBs are always supposed to be identical. Cheers, Adam
[jira] Closed: (COUCHDB-589) Simplify Query Server interface and Design Handlers
[ https://issues.apache.org/jira/browse/COUCHDB-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-589. Resolution: Fixed Fix Version/s: 0.11 r906721 commits a patch that re-enables 404 handling in show functions. If a show function that doesn't explicitly handles the 404 case (i.e. throws a null-exception), CouchDB still returns a 404 error for the user instead of blowing up in a 500 error. The only change towards older behaviour is that req.docId is now called req.id. Simplify Query Server interface and Design Handlers --- Key: COUCHDB-589 URL: https://issues.apache.org/jira/browse/COUCHDB-589 Project: CouchDB Issue Type: Improvement Components: JavaScript View Server Reporter: Chris Anderson Assignee: Chris Anderson Fix For: 0.11 Attachments: ddoc_qs.patch, design_handlers.patch, show_handle.404-2.patch, show_handle.404.diff This patch refactors list, show, update, filter, and view handling to have a unified interface for loading the design document and functions from it. It is a step on the path to removing a lot of function src passing overhead from the view server protocol. The patch also removes some old part of the API while improving other parts of the API. The big changes: Load the design document before handing it to the design document handlers. This removes a lot of duplicated code. Remove /db/_view handler. I think it's in our interest to remove the last bits of the old-style API before 0.11. I also clean up some rough edges in the API. I plan to commit this patch soon, but want to give people an opportunity to look it over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-639) Pull replication should profit of compressed attachments for higher performance
Pull replication should profit of compressed attachments for higher performance --- Key: COUCHDB-639 URL: https://issues.apache.org/jira/browse/COUCHDB-639 Project: CouchDB Issue Type: Improvement Components: Replication Affects Versions: 0.11 Environment: trunk Reporter: Filipe Manana Attachments: pull-rep-att-comp.patch Currently, when doing a pull replication where there are docs at the source DB with compressed attachments: 1) The source decompresses the attachment before sending it to the target DB 2) The target compresses the attachment before storing it Clearly, a waste of CPU, bandwidth and disk IO. The following patch fixes the issue. JavaScript test included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-639) Pull replication should profit of compressed attachments for higher performance
[ https://issues.apache.org/jira/browse/COUCHDB-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-639: -- Attachment: pull-rep-att-comp.patch Pull replication should profit of compressed attachments for higher performance --- Key: COUCHDB-639 URL: https://issues.apache.org/jira/browse/COUCHDB-639 Project: CouchDB Issue Type: Improvement Components: Replication Affects Versions: 0.11 Environment: trunk Reporter: Filipe Manana Attachments: pull-rep-att-comp.patch Currently, when doing a pull replication where there are docs at the source DB with compressed attachments: 1) The source decompresses the attachment before sending it to the target DB 2) The target compresses the attachment before storing it Clearly, a waste of CPU, bandwidth and disk IO. The following patch fixes the issue. JavaScript test included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
