Re: 1.2.0 status update
On Wed, Mar 14, 2012 at 4:04 AM, Benoit Chesneau wrote: > On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith wrote: >> IMHO: >> >> It affects advanced users, with multiple JS builds installed. It is >> not a 1.2.0 blocker. It's not relevant to this discussion. > > It is. If you reread the ticket it appears that the problem is more > important than expected and I hesitated a lot to let it as blocker > like it was initially. Since the release have been postponed, we aslo > have the perfect opportunity to really fix that issue. Hi, Benoit. You make a strong point. I noticed your March 02 update to issue 1426. I interpreted that to mean that 1.2.0 can ship without the bugfix. I **thought** 1.1.1 also shipped with this bug, in which case it seems not so severe. (If I am wrong, then I stand corrected.) -- Iris Couch
Re: Fundamentals Question on CoucheDB's append only b+tree.
On Tue, Mar 13, 2012 at 11:33 PM, Randall Leeds wrote: > On Mar 13, 2012 7:11 PM, "Paul Davis" wrote: >> >> On Tue, Mar 13, 2012 at 5:50 PM, Bob Dionne >> wrote: >> > That's largely correct, though couchdb's btree is neither fish nor fowl. >> > >> > It doesn't have an order (B-trees generally do) and it does store > values in the inner nodes (B+trees do not) >> > >> >> The lack of order is the big thing. > > What is meant by order in this context? Maximum number of elements in a node. Ie, the whole "every node except the root must have between N/2 and N elements at all times" thing.
Re: Fundamentals Question on CoucheDB's append only b+tree.
On Mar 13, 2012 7:11 PM, "Paul Davis" wrote: > > On Tue, Mar 13, 2012 at 5:50 PM, Bob Dionne > wrote: > > That's largely correct, though couchdb's btree is neither fish nor fowl. > > > > It doesn't have an order (B-trees generally do) and it does store values in the inner nodes (B+trees do not) > > > > The lack of order is the big thing. What is meant by order in this context?
Re: 1.2.0 status update
On Tue, Mar 13, 2012 at 7:47 PM, Jason Smith wrote: > IMHO: > > It affects advanced users, with multiple JS builds installed. It is > not a 1.2.0 blocker. It's not relevant to this discussion. It is. If you reread the ticket it appears that the problem is more important than expected and I hesitated a lot to let it as blocker like it was initially. Since the release have been postponed, we aslo have the perfect opportunity to really fix that issue. Lot of our users are complaining to have some problem installing couchdb on their machine. This isn't new. This isn't solved. While the lazy solution was to direct them to couchbase stuff, or these days to build_couchdb or rcouch, I would really prefer we fix this *important* issue and let people choose if they prefer to install via a vendor or the official *distribution*. Last iteration of the patch fix most of the cases I guess. We can choose like said above to use this version and fix latest issues in next minor release or trying to solve that last one. At this point, after different iterations, feedback is appreciated and that is the main reason why updates of the tickets are sent to the ml. - benoit
Re: 1.2.0 status update
IMHO: It affects advanced users, with multiple JS builds installed. It is not a 1.2.0 blocker. It's not relevant to this discussion. In the meantime, I have been prepping all the Linux VMs I can find to test for the next 1.2.0 vote. On Wed, Mar 14, 2012 at 8:59 AM, Paul Davis wrote: > On Tue, Mar 13, 2012 at 8:27 PM, Noah Slater wrote: >> Thanks Dave. >> >> On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber wrote: >>> >>> What's the plan to move forwards here? We are damn close but a half >>> finished solution for 1426 will >>> simply mean another round. This needs more collaboration so that we >>> are not working async on this. >>> >> >> I don't think we are damn close. >> >> We've seen hardly any progress with this issue during the week and a half >> since Benoît took ownership of it. That tells me that it can't be very >> important, and so I will attempt another vote tomorrow, with or without it. >> >> If someone, anyone, wants to land a fix for it between now and then, be my >> guest. But I will not hold the release up any longer for an issue that >> nobody can be bothered to fix. >> >> (Not to discredit the work already put in to it. I really appreciate that. >> Seriously, I do. But it's obviously not important enough to block the >> release any longer, or it would've been fixed already. Actions speak louder >> than words.) > > While I appreciate your enthusiasm, you appear to have not been > following the issue very closely. There have been two versions of > Benoit's initial work in the last week with multiple test reports [1]. > The current issue is that Dave has a machine that has a broken > configuration. We need to figure out if we want to dig deeper into > that or just assume that it's a broken configuration and thus outside > our control. Once we have a decision there we can either commit > Benoit's latest patch or fix it up to hack around that last edge case. > > > [1] https://issues.apache.org/jira/browse/COUCHDB-1426 -- Iris Couch
Re: Fundamentals Question on CoucheDB's append only b+tree.
On Tue, Mar 13, 2012 at 5:50 PM, Bob Dionne wrote: > That's largely correct, though couchdb's btree is neither fish nor fowl. > > It doesn't have an order (B-trees generally do) and it does store values in > the inner nodes (B+trees do not) > The lack of order is the big thing. Though I'd slightly disagree with the no values in inner nodes assessment. Strictly speaking, I would say they do not as to get a key's value you have to read through to a leaf node. I would guess that you're referring to the reduction values stored on internal nodes, and while they are "values" technically, they aren't the "value" of the "key/value" type. Specifically, they don't have a 1:1 mapping to keys. IOW, the internal storage of reductions directly in the inner-nodes is an extension to the b+tree algorithm that could be done perfectly validly in a textbook example of b+trees. OTOH, I definitely agree about the lack of order. Sadly each time I've tried to enforce that I end up making the whole thing considerably slower so in this case engineering pragmatism wins over theoretical purity. > As Paul might say it's a B~tree > > > On Mar 13, 2012, at 3:31 PM, Randall Leeds wrote: > >> On Tue, Mar 13, 2012 at 10:40, Robert Newson wrote: >> >>> There's no linked list running between the leafs. A b+tree doesn't >>> require one, though it's a common addition. The b+tree algorithm is a >>> revision over a binary tree (where inner nodes point strictly at one >>> left and one right item). To be a b+tree you need to hold many >>> pointers on an inner node. >>> >> >> I thought being a B-tree was to have many pointers in inner nodes, being a >> B+tree was to have *only* pointers in inner nodes and the values all at the >> leaf nodes. >> Whatever it's called, the latter is what CouchDB has. >
Re: 1.2.0 status update
On Tue, Mar 13, 2012 at 8:27 PM, Noah Slater wrote: > Thanks Dave. > > On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber wrote: >> >> What's the plan to move forwards here? We are damn close but a half >> finished solution for 1426 will >> simply mean another round. This needs more collaboration so that we >> are not working async on this. >> > > I don't think we are damn close. > > We've seen hardly any progress with this issue during the week and a half > since Benoît took ownership of it. That tells me that it can't be very > important, and so I will attempt another vote tomorrow, with or without it. > > If someone, anyone, wants to land a fix for it between now and then, be my > guest. But I will not hold the release up any longer for an issue that > nobody can be bothered to fix. > > (Not to discredit the work already put in to it. I really appreciate that. > Seriously, I do. But it's obviously not important enough to block the > release any longer, or it would've been fixed already. Actions speak louder > than words.) While I appreciate your enthusiasm, you appear to have not been following the issue very closely. There have been two versions of Benoit's initial work in the last week with multiple test reports [1]. The current issue is that Dave has a machine that has a broken configuration. We need to figure out if we want to dig deeper into that or just assume that it's a broken configuration and thus outside our control. Once we have a decision there we can either commit Benoit's latest patch or fix it up to hack around that last edge case. [1] https://issues.apache.org/jira/browse/COUCHDB-1426
Re: 1.2.0 status update
Just to clarify, Benoît only agreed to drive it. Driving might've been landing it, or it might've been organising other people to land it. I appreciate the work that both Benoît and Paul have put in. Obviously, they both "bothered" to help out here. But anyone else could've chipped in at any point. It's a shame that didn't happen, but it's not the end of the world. I think it's safe to assume, from the lack of people rushing to get this fixed during the last two weeks, that it can wait until 1.2.1. Unless it get's fixed tonight while I sleep... ;) On Wed, Mar 14, 2012 at 1:56 AM, Randall Leeds wrote: > On Tue, Mar 13, 2012 at 18:27, Noah Slater wrote: > > > Thanks Dave. > > > > On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber > > wrote: > > > > > > What's the plan to move forwards here? We are damn close but a half > > > finished solution for 1426 will > > > simply mean another round. This needs more collaboration so that we > > > are not working async on this. > > > > > > > I don't think we are damn close. > > > > We've seen hardly any progress with this issue during the week and a half > > since Benoît took ownership of it. That tells me that it can't be very > > important, and so I will attempt another vote tomorrow, with or without > it. > > > > To be fair, I saw a couple iterations from Paul and some work from Benoit > and I know Benoit has been at PyCon and busy with python things. > But I agree, I don't see it as a blocker. >
Re: 1.2.0 status update
On Tue, Mar 13, 2012 at 18:27, Noah Slater wrote: > Thanks Dave. > > On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber > wrote: > > > > What's the plan to move forwards here? We are damn close but a half > > finished solution for 1426 will > > simply mean another round. This needs more collaboration so that we > > are not working async on this. > > > > I don't think we are damn close. > > We've seen hardly any progress with this issue during the week and a half > since Benoît took ownership of it. That tells me that it can't be very > important, and so I will attempt another vote tomorrow, with or without it. > To be fair, I saw a couple iterations from Paul and some work from Benoit and I know Benoit has been at PyCon and busy with python things. But I agree, I don't see it as a blocker.
Re: 1.2.0 status update
Thanks Dave. On Tue, Mar 13, 2012 at 11:20 PM, Dave Cottlehuber wrote: > > What's the plan to move forwards here? We are damn close but a half > finished solution for 1426 will > simply mean another round. This needs more collaboration so that we > are not working async on this. > I don't think we are damn close. We've seen hardly any progress with this issue during the week and a half since Benoît took ownership of it. That tells me that it can't be very important, and so I will attempt another vote tomorrow, with or without it. If someone, anyone, wants to land a fix for it between now and then, be my guest. But I will not hold the release up any longer for an issue that nobody can be bothered to fix. (Not to discredit the work already put in to it. I really appreciate that. Seriously, I do. But it's obviously not important enough to block the release any longer, or it would've been fixed already. Actions speak louder than words.)
[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed
[ https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228808#comment-13228808 ] Dave Cottlehuber commented on COUCHDB-1426: --- Thanks Paul & Benoit for helping me on this. My newish linux mint debian, has a /usr/lib/pkgconfig/mozilla-js.pc that points to files that don't exist http://friendpaste.com/1yuN07ZWGTiKQoh47WyFRb and this breaks the configure using above patch. Not sure if this is common case - config.log here http://friendpaste.com/1QhtlBaCUw9RLpPj3UNCrC . mozjs is in /usr/include /usr/lib etc as normal, and is found correctly by current 1.2.x git. > error while building with 2 spidermonkey installed > -- > > Key: COUCHDB-1426 > URL: https://issues.apache.org/jira/browse/COUCHDB-1426 > Project: CouchDB > Issue Type: Bug > Components: Build System >Affects Versions: 1.1.1, 1.2, 1.3 >Reporter: Benoit Chesneau >Assignee: Benoit Chesneau >Priority: Critical > Attachments: 0001-close-COUCHDB-1426.patch, > 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, > 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, > 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, > 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, > 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, COUCHDB-1426.patch > > > Context: > To bench the differences between different versions of couchdb I had to test > against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in > /usr/local while the 1.7 version is installed on a temporary path. > Problem: > Using --witth-js-include & --with-js-lib configure options aren't enough to > use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing > js-config from the path doesn't change anything. I had to uninstall > spidermonkey 1.8.5 to have these setting working. > Error result: > $ ./configure > --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include > --with-js-include=/Users/benoitc/local/js-1.7.0/include > --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64 > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... build-aux/install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking build system type... i386-apple-darwin11.3.0 > checking host system type... i386-apple-darwin11.3.0 > checking for a sed that does not truncate output... /usr/bin/sed > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for fgrep... /usr/bin/grep -F > checking for ld used by gcc... > /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld > checking if the linker > (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm > checking the name lister (/usr/bin/nm) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 196608 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld > option to reload object files... -r > checking how to recognize dependent libraries... pass_all > checking for ar... ar > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /usr/bin/nm output from gcc object... ok > checking for dsymutil... dsymutil > checking for nmedit... nmedit > checking for lipo... lipo > checking for otool... otool > checking for otool64... no > checking for -single_module linker flag... yes > checking for -exported_symbols_list linker flag... yes > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.
Re: 1.2.0 status update
Thanks for the summary Dave, this is helpful to keep everyone in the loop :) On Mar 14, 2012, at 00:20 , Dave Cottlehuber wrote: > Brief update from today. > > etag_views issue emerged, Jan and Filipe sorted that out already & its > been committed. > Sorry; I was aware of it but didn't raise it as I wasn't sure it was > actually a couch issue. > > Following that I got all etaps and futon tests passing on FF Aurora 12, > running > Couch on Mac Lion and Linux Mint Debian Edition. If somebody can > confirm for ubuntu that > would be a help - any other OS reqd? > > I slowly worked my up past gpg signing in the release procedure (all > good) but died at > the md5 stage due to md5sum not being installed. I can see why some of > this takes a while. > > I am not clear whether the PMC have made a call on including > COUCHDB-1426 or not; > but either way we need to ensure we have: > - out of the box builds on most sensible platform default configurations > - a clear statement on how to build against a compatible SpiderMonkey > when the above doesn't apply. > > From what Benoît says, the current approach doesn't handle the latter, > so I think we need to complete > the patch. > > What's the plan to move forwards here? We are damn close but a half > finished solution for 1426 will > simply mean another round. This needs more collaboration so that we > are not working async on this. > > Can we organise enough people tomorrow evening (Euro time / daytime US > time) to nail this specific issue? > Or you can sort it while I sleep ;-) The PMC hasn't decided on this in particular, but we (dev@) agreed last week that 1426 is a nice to have for 1.2.0 but not a blocker and that we should fix it asap, but if we can't make it for 1.2.0, we should include the fix in a 1.2.1 shortly after and document the situation for 1.2.0. I welcome any efforts to tag team the issue, but we shouldn't hold 1.2.0 for this. :) Cheers Jan -- > > > A+ > Dave > > > On 9 March 2012 21:30, Noah Slater wrote: >> Cool. Please circle back here and let me know when I am good to call 1.2.0. >> >> We're waiting on you Paul. No pressure. ;) >> >> (Seriously, thanks!) >> >> On Fri, Mar 9, 2012 at 8:24 PM, Paul Davis >> wrote: >> >>> Will review this as soon as I catch up on what happened on the >>> internet whilst I was sleeping. >>> >>> On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau >>> wrote: On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater >>> wrote: > Woot, thanks. > > How's your stuff going, Benoît? Sorry have been distracted by some due work yesterday. I updated the ticket with a new version of the patch. Hopefully we aren't so far. I tested it in different scenarios and it worked. If anyone can review it that would help. - benoît >>>
Re: 1.2.0 status update
Brief update from today. etag_views issue emerged, Jan and Filipe sorted that out already & its been committed. Sorry; I was aware of it but didn't raise it as I wasn't sure it was actually a couch issue. Following that I got all etaps and futon tests passing on FF Aurora 12, running Couch on Mac Lion and Linux Mint Debian Edition. If somebody can confirm for ubuntu that would be a help - any other OS reqd? I slowly worked my up past gpg signing in the release procedure (all good) but died at the md5 stage due to md5sum not being installed. I can see why some of this takes a while. I am not clear whether the PMC have made a call on including COUCHDB-1426 or not; but either way we need to ensure we have: - out of the box builds on most sensible platform default configurations - a clear statement on how to build against a compatible SpiderMonkey when the above doesn't apply. >From what Benoît says, the current approach doesn't handle the latter, so I think we need to complete the patch. What's the plan to move forwards here? We are damn close but a half finished solution for 1426 will simply mean another round. This needs more collaboration so that we are not working async on this. Can we organise enough people tomorrow evening (Euro time / daytime US time) to nail this specific issue? Or you can sort it while I sleep ;-) A+ Dave On 9 March 2012 21:30, Noah Slater wrote: > Cool. Please circle back here and let me know when I am good to call 1.2.0. > > We're waiting on you Paul. No pressure. ;) > > (Seriously, thanks!) > > On Fri, Mar 9, 2012 at 8:24 PM, Paul Davis wrote: > >> Will review this as soon as I catch up on what happened on the >> internet whilst I was sleeping. >> >> On Fri, Mar 9, 2012 at 8:53 AM, Benoit Chesneau >> wrote: >> > On Fri, Mar 9, 2012 at 4:05 AM, Noah Slater >> wrote: >> >> Woot, thanks. >> >> >> >> How's your stuff going, Benoît? >> > >> > >> > Sorry have been distracted by some due work yesterday. I updated the >> > ticket with a new version of the patch. >> > >> > Hopefully we aren't so far. I tested it in different scenarios and it >> > worked. If anyone can review it that would help. >> > >> > - benoît >>
Re: Fundamentals Question on CoucheDB's append only b+tree.
That's largely correct, though couchdb's btree is neither fish nor fowl. It doesn't have an order (B-trees generally do) and it does store values in the inner nodes (B+trees do not) As Paul might say it's a B~tree On Mar 13, 2012, at 3:31 PM, Randall Leeds wrote: > On Tue, Mar 13, 2012 at 10:40, Robert Newson wrote: > >> There's no linked list running between the leafs. A b+tree doesn't >> require one, though it's a common addition. The b+tree algorithm is a >> revision over a binary tree (where inner nodes point strictly at one >> left and one right item). To be a b+tree you need to hold many >> pointers on an inner node. >> > > I thought being a B-tree was to have many pointers in inner nodes, being a > B+tree was to have *only* pointers in inner nodes and the values all at the > leaf nodes. > Whatever it's called, the latter is what CouchDB has.
Re: Enforced filter functions
Summarizing some things I said on IRC: I'm more than a little nervous about any more steps that appear to give fine-grained read access control within a database. We have repeatedly rejected the idea when it's been raised by community members citing the numerous problems that come with it (data leaking via views, for example) so we risk introducing even more confusion with a volte face. If we pursue this, we must get it right. Today there's at least one case where we currently have mandatory code execution, validate_doc_update, that is causing issues. Because it cannot be bypassed, even by an admin, BigCouch, which strives to make N copies of every document, can be hindered. This example illustrates some part of the danger that 'enforced' code execution brings. Dale does state that the proposed filters would affect non-admins but we should be be conscious of how different couchdb looks and behaves to users vs admins. I agree completely that we need to add features incrementally rather than attempt some giant feat within a release. What I haven't yet heard is a coherent plan for where we'll end up. As a committer, I share responsibility in helping to define and deliver that plan. B. On 13 March 2012 15:33, Dale Harvey wrote: > On 13 March 2012 15:30, Dale Harvey wrote: > >> So I was trying to implement the ability for logged in users to subscribe >> to the changes feed for updates to their own documents (its currently admin >> only), its a simple patch but its not very clean (mostly because the we >> dont want to have the changes feed read the full document) >> >> A way that I could implement it, that seems a lot more globally applicable >> and applies cleaner, is to allow the ddoc author to enforce filters to >> happen on non admin access to _changes and replication (on any database) >> >> This should negatively affect anything else, filters are already used and >> supported in both places, I have also seen it asked for regularly in the >> context of replication, ddoc authors could specify exactly what users are >> allowed to replicate, the enforced filter would override any users filter >> >> > Obviously I meant "should not negatively affect" :) > > >> As far as I can tell the only problem would be how to have the author >> specify the enforcement, apart from that it should apply cleanly, >> introduces a fairly large amount of new functionality and adds very little >> overhead >> >> Ideas? >> >> Jan mentioned this could be used more widely for updates / shows / lists, >> that is starting to sound more complicated and does start introducing >> problems, I would prefer to look at the simple case of filters for changes >> / replication for now, but if there was an even more global solution that >> applied cleanly, I would be happy to >> >> >>
Re: Fundamentals Question on CoucheDB's append only b+tree.
what Randall said :P On 13 March 2012 19:31, Randall Leeds wrote: > On Tue, Mar 13, 2012 at 10:40, Robert Newson wrote: > >> There's no linked list running between the leafs. A b+tree doesn't >> require one, though it's a common addition. The b+tree algorithm is a >> revision over a binary tree (where inner nodes point strictly at one >> left and one right item). To be a b+tree you need to hold many >> pointers on an inner node. >> > > I thought being a B-tree was to have many pointers in inner nodes, being a > B+tree was to have *only* pointers in inner nodes and the values all at the > leaf nodes. > Whatever it's called, the latter is what CouchDB has.
Re: Enforced filter functions
Another way to solve the particular feature would be "per-doc changes": GET /db/doc/_changes I can see tons of use-cases for that already :) Cheers Jan -- On Mar 13, 2012, at 21:17 , Dale Harvey wrote: > Yup as Jan said, even the 'only run on non admin access' can live inside > the filter (there may be performance reasons to want to avoid that though) > > Robert has expressed some concerns on irc about the implementation of > various security related features in an adhoc way, I do agree, the entire > reason I proposed this was to avoid a special case for subscribing to the > users table. > > I think with some eye to the future this can be implemented in a way that > builds towards a reasonably complete set of security functionality, I dont > think it needs to be another edge case feature, I will try to come up with > a proposal that keeps in mind new things that couch will likely want to > implement > > Any things to keep in mind, or other proposals would be nice > > On 13 March 2012 19:36, Jan Lehnardt wrote: > >> >> On Mar 13, 2012, at 20:32 , Randall Leeds wrote: >> >>> Do filters already have access to the user context? My first thought is >>> that this would allow such a filter function to be written (one that >> works >>> for all users, but filters based on user). >> >> Yes. >> >> The problem with your suggestion is that the client can optionally specify >> the filter, or not, thus bypassing it. >> >> Cheers >> Jan >> -- >> >>> >>> On Tue, Mar 13, 2012 at 08:33, Dale Harvey wrote: >>> On 13 March 2012 15:30, Dale Harvey wrote: > So I was trying to implement the ability for logged in users to >> subscribe > to the changes feed for updates to their own documents (its currently admin > only), its a simple patch but its not very clean (mostly because the we > dont want to have the changes feed read the full document) > > A way that I could implement it, that seems a lot more globally applicable > and applies cleaner, is to allow the ddoc author to enforce filters to > happen on non admin access to _changes and replication (on any >> database) > > This should negatively affect anything else, filters are already used >> and > supported in both places, I have also seen it asked for regularly in >> the > context of replication, ddoc authors could specify exactly what users >> are > allowed to replicate, the enforced filter would override any users >> filter > > Obviously I meant "should not negatively affect" :) > As far as I can tell the only problem would be how to have the author > specify the enforcement, apart from that it should apply cleanly, > introduces a fairly large amount of new functionality and adds very little > overhead > > Ideas? > > Jan mentioned this could be used more widely for updates / shows / >> lists, > that is starting to sound more complicated and does start introducing > problems, I would prefer to look at the simple case of filters for changes > / replication for now, but if there was an even more global solution >> that > applied cleanly, I would be happy to > > > >> >>
Re: Enforced filter functions
Yup as Jan said, even the 'only run on non admin access' can live inside the filter (there may be performance reasons to want to avoid that though) Robert has expressed some concerns on irc about the implementation of various security related features in an adhoc way, I do agree, the entire reason I proposed this was to avoid a special case for subscribing to the users table. I think with some eye to the future this can be implemented in a way that builds towards a reasonably complete set of security functionality, I dont think it needs to be another edge case feature, I will try to come up with a proposal that keeps in mind new things that couch will likely want to implement Any things to keep in mind, or other proposals would be nice On 13 March 2012 19:36, Jan Lehnardt wrote: > > On Mar 13, 2012, at 20:32 , Randall Leeds wrote: > > > Do filters already have access to the user context? My first thought is > > that this would allow such a filter function to be written (one that > works > > for all users, but filters based on user). > > Yes. > > The problem with your suggestion is that the client can optionally specify > the filter, or not, thus bypassing it. > > Cheers > Jan > -- > > > > > On Tue, Mar 13, 2012 at 08:33, Dale Harvey wrote: > > > >> On 13 March 2012 15:30, Dale Harvey wrote: > >> > >>> So I was trying to implement the ability for logged in users to > subscribe > >>> to the changes feed for updates to their own documents (its currently > >> admin > >>> only), its a simple patch but its not very clean (mostly because the we > >>> dont want to have the changes feed read the full document) > >>> > >>> A way that I could implement it, that seems a lot more globally > >> applicable > >>> and applies cleaner, is to allow the ddoc author to enforce filters to > >>> happen on non admin access to _changes and replication (on any > database) > >>> > >>> This should negatively affect anything else, filters are already used > and > >>> supported in both places, I have also seen it asked for regularly in > the > >>> context of replication, ddoc authors could specify exactly what users > are > >>> allowed to replicate, the enforced filter would override any users > filter > >>> > >>> > >> Obviously I meant "should not negatively affect" :) > >> > >> > >>> As far as I can tell the only problem would be how to have the author > >>> specify the enforcement, apart from that it should apply cleanly, > >>> introduces a fairly large amount of new functionality and adds very > >> little > >>> overhead > >>> > >>> Ideas? > >>> > >>> Jan mentioned this could be used more widely for updates / shows / > lists, > >>> that is starting to sound more complicated and does start introducing > >>> problems, I would prefer to look at the simple case of filters for > >> changes > >>> / replication for now, but if there was an even more global solution > that > >>> applied cleanly, I would be happy to > >>> > >>> > >>> > >> > >
Re: Couchbase trademark issues
On Mar 13, 2012, at 20:52 , Miles Fidelman wrote: > Jan Lehnardt wrote: >> >> I'd be interested to hear what other measures you think Couchbase could >> take? Feel free to take this to priv...@apache.couchdb.org to discuss >> with the PMC as well. >> > One that that might help a lot is a really serious definition of what > Couchbase is - particularly in visible locations like the front page of > couchbase.com. While the name implies a close relationship to CouchDB, I > really can't, for the life of me, find a clear description of what it does. > > I mean, CouchDB is very clearly: > - "a document-oriented database that can be queried and indexed using > JavaScript in a MapReduce fashion" > - "A document database server, accessible via a RESTful JSON API." > with http://couchdb.apache.org/docs/intro.html and > http://couchdb.apache.org/docs/overview.html elaborating quite nicely. > (Less visible is that CouchDB is a great application development platform. I > refer to couchapps, of course). > > On the other hand, all I can figure out from couchbase.com is: > - "Couchbase is open source NoSQL for mission-critical systems." and that one > can > - "spread your data across a cluster of machines and randomly access it with > sub-millisecond latency" > - and it's pretty quickly obvious that the most salient features of CouchDB > (RESTful interface, application platform) are missing from Couchbase > - by and large, it's completely useless for the kinds of things I'm working > on (except maybe as a backend to add some scalability down the line) > > What CouchDB is, and why one might use it is very clearly defined. > > On the other hand, Couchbase materials (website, white paper, ...) make a > generic case for NoSQL databases - but one that could equally apply to > Hadoop, Riak, graph databases, and the whole range of NoSQL technologies and > products. > > Seems to me that not only would a very clear use case and functional > description for Couchbase help distinguish the two, but would also help > Couchbase position itself in the space of available technologies and in the > marketplace. If anything, the "Couch" in Couchbase implies that it's > something like CouchDB - which it really isn't. At best, it's not very > helpful, at worst it's rather misleading. [Couchbase hat]: Thanks for the input, we hope to address these things on our website, please await my report before suggesting other things for the website. I was looking for *additional* things you might think we can do. Cheers Jan -- > > Miles Fidelman > > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra > >
Re: Couchbase trademark issues
Jan Lehnardt wrote: I'd be interested to hear what other measures you think Couchbase could take? Feel free to take this to priv...@apache.couchdb.org to discuss with the PMC as well. One that that might help a lot is a really serious definition of what Couchbase is - particularly in visible locations like the front page of couchbase.com. While the name implies a close relationship to CouchDB, I really can't, for the life of me, find a clear description of what it does. I mean, CouchDB is very clearly: - "a document-oriented database that can be queried and indexed using JavaScript in a MapReduce fashion" - "A document database server, accessible via a RESTful JSON API." with http://couchdb.apache.org/docs/intro.html and http://couchdb.apache.org/docs/overview.html elaborating quite nicely. (Less visible is that CouchDB is a great application development platform. I refer to couchapps, of course). On the other hand, all I can figure out from couchbase.com is: - "Couchbase is open source NoSQL for mission-critical systems." and that one can - "spread your data across a cluster of machines and randomly access it with sub-millisecond latency" - and it's pretty quickly obvious that the most salient features of CouchDB (RESTful interface, application platform) are missing from Couchbase - by and large, it's completely useless for the kinds of things I'm working on (except maybe as a backend to add some scalability down the line) What CouchDB is, and why one might use it is very clearly defined. On the other hand, Couchbase materials (website, white paper, ...) make a generic case for NoSQL databases - but one that could equally apply to Hadoop, Riak, graph databases, and the whole range of NoSQL technologies and products. Seems to me that not only would a very clear use case and functional description for Couchbase help distinguish the two, but would also help Couchbase position itself in the space of available technologies and in the marketplace. If anything, the "Couch" in Couchbase implies that it's something like CouchDB - which it really isn't. At best, it's not very helpful, at worst it's rather misleading. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: Enforced filter functions
On Mar 13, 2012, at 20:32 , Randall Leeds wrote: > Do filters already have access to the user context? My first thought is > that this would allow such a filter function to be written (one that works > for all users, but filters based on user). Yes. The problem with your suggestion is that the client can optionally specify the filter, or not, thus bypassing it. Cheers Jan -- > > On Tue, Mar 13, 2012 at 08:33, Dale Harvey wrote: > >> On 13 March 2012 15:30, Dale Harvey wrote: >> >>> So I was trying to implement the ability for logged in users to subscribe >>> to the changes feed for updates to their own documents (its currently >> admin >>> only), its a simple patch but its not very clean (mostly because the we >>> dont want to have the changes feed read the full document) >>> >>> A way that I could implement it, that seems a lot more globally >> applicable >>> and applies cleaner, is to allow the ddoc author to enforce filters to >>> happen on non admin access to _changes and replication (on any database) >>> >>> This should negatively affect anything else, filters are already used and >>> supported in both places, I have also seen it asked for regularly in the >>> context of replication, ddoc authors could specify exactly what users are >>> allowed to replicate, the enforced filter would override any users filter >>> >>> >> Obviously I meant "should not negatively affect" :) >> >> >>> As far as I can tell the only problem would be how to have the author >>> specify the enforcement, apart from that it should apply cleanly, >>> introduces a fairly large amount of new functionality and adds very >> little >>> overhead >>> >>> Ideas? >>> >>> Jan mentioned this could be used more widely for updates / shows / lists, >>> that is starting to sound more complicated and does start introducing >>> problems, I would prefer to look at the simple case of filters for >> changes >>> / replication for now, but if there was an even more global solution that >>> applied cleanly, I would be happy to >>> >>> >>> >>
Re: Enforced filter functions
Do filters already have access to the user context? My first thought is that this would allow such a filter function to be written (one that works for all users, but filters based on user). On Tue, Mar 13, 2012 at 08:33, Dale Harvey wrote: > On 13 March 2012 15:30, Dale Harvey wrote: > > > So I was trying to implement the ability for logged in users to subscribe > > to the changes feed for updates to their own documents (its currently > admin > > only), its a simple patch but its not very clean (mostly because the we > > dont want to have the changes feed read the full document) > > > > A way that I could implement it, that seems a lot more globally > applicable > > and applies cleaner, is to allow the ddoc author to enforce filters to > > happen on non admin access to _changes and replication (on any database) > > > > This should negatively affect anything else, filters are already used and > > supported in both places, I have also seen it asked for regularly in the > > context of replication, ddoc authors could specify exactly what users are > > allowed to replicate, the enforced filter would override any users filter > > > > > Obviously I meant "should not negatively affect" :) > > > > As far as I can tell the only problem would be how to have the author > > specify the enforcement, apart from that it should apply cleanly, > > introduces a fairly large amount of new functionality and adds very > little > > overhead > > > > Ideas? > > > > Jan mentioned this could be used more widely for updates / shows / lists, > > that is starting to sound more complicated and does start introducing > > problems, I would prefer to look at the simple case of filters for > changes > > / replication for now, but if there was an even more global solution that > > applied cleanly, I would be happy to > > > > > > >
Re: Fundamentals Question on CoucheDB's append only b+tree.
On Tue, Mar 13, 2012 at 10:40, Robert Newson wrote: > There's no linked list running between the leafs. A b+tree doesn't > require one, though it's a common addition. The b+tree algorithm is a > revision over a binary tree (where inner nodes point strictly at one > left and one right item). To be a b+tree you need to hold many > pointers on an inner node. > I thought being a B-tree was to have many pointers in inner nodes, being a B+tree was to have *only* pointers in inner nodes and the values all at the leaf nodes. Whatever it's called, the latter is what CouchDB has.
Re: Couchbase trademark issues
On Mar 13, 2012, at 14:52 , Robert Newson wrote: > I don't believe any CouchDB committer or PMC member has any interest > in changing the project name. > > I personally feel, as you do, that it's the other products that must > clearly distinguish themselves from CouchDB. The company and product > called "Couchbase" clearly confuses the community, who reasonably, but > erroneously, believe that it's related to CouchDB (the truth, now, is > that couchdb is an important but internal component). Sponsoring the > "CouchConf" conferences which talks about "Couch NoSQL technology" but > also "the Couchbase technology" is similarly confusing, especially as > "CouchConf"'s in the past were about Apache CouchDB and things > compatible or complementary to it. > > For my part, the ideal solution would be for Couchbase to rename its > product and conferences to not imply that they are about CouchDB, to > me that means not using the word 'couch'. I understand that the > trademark we hold is on 'Apache CouchDB' and that we cannot assert any > rights over the word 'couch', but I don't think anyone can deny that > confusion caused is real. Since the Couchbase product is not CouchDB > compatible it's surprising that it hasn't been rebranded for marketing > reasons already. [both hats]: While I agree that, looking solely at a potential confusion issue, a rename would be a big step towards avoiding said issue, it is also not very practical (as per Shane, things aren't binary) to expect Couchbase to change their naming. I'd be interested to hear what other measures you think Couchbase could take? Feel free to take this to priv...@apache.couchdb.org to discuss with the PMC as well. Cheers Jan -- > > B. > > On 13 March 2012 04:01, Shane Curcuru wrote: >> (Whoops! Apologies for mixed up subjects and poor threading; I'm not on >> dev@) >> >> I just wanted to add one other comment about this previous note: >> >> James Hayton wrote on Feb 20, 2012: >>> >>> Maybe a crazy idea, but since the end result of any legal stuff would >>> be somebody changing the name of something, why doesn't Apache >>> CouchDB just re brand itself? I mean we need a website makeover, >>> etc... Why don't we just ditch the name and come up with something >>> better with a new vision, new leadership, etc... Lets put a few >>> features in that people have been asking for, include the big couch >>> code (clustering), create a new website and call it something >>> different. (CouchDB 2.0 Becomes AwesomeDB lol) >>> >>> I understand that alot of people have quite a bit invested in the >>> name CouchDB, at this may not be something realistic, but this just >>> seems like at least another option we should discuss. >>> >>> Just my .02. >>> >>> James >> >> >> If the bulk of the Apache CouchDB PMC truly wanted to consider a rename (and >> discussed and [VOTE]d on the matter, then we'd certainly help that to >> happen. The PMC *is* who gets to decide the project direction. >> >> But I'm confident that's *not* the case, since several folks have spoken out >> against it. I personally think it would be a really bad idea to change the >> CouchDB name - especially since CouchDB is arguably the first project that >> gave such brand recognition to the "Couch" name in the noSQL database arena. >> >> In most trademark issues, I'd think more people would ask why the >> *follow-on* products don't change their names, rather than the original >> product. But in this case, I'm hoping that the pain of renaming is not >> necessary, and we can reduce user confusion by both improving our own story, >> as well as asking other Couch-named products to better differentiate >> themselves and better give us - this PMC, the committers, and the ASF - the >> credit we deserve for building and shipping Apache CouchDB itself in the >> first place. >> >> - Shane >>
Re: Seeking CouchDB guidance
Thanks Shane, This is very helpful! I'll reply in more detail inline. I just want to make sure to note that I'm am wearing two hats in this matter, my Apache CouchDB PMC Chair hat and my Couchbase co-founder hat. I'll denote when I'm speaking for which accordingly. On Mar 13, 2012, at 04:50 , Shane Curcuru wrote: > (Apologies for coming late to this thread; note I'm not on dev@) > (cc: trademarks@ for FYI) > > On 2012-02-22 6:02 PM, Noah Slater wrote: >> Hello, >> >> I am reaching out to you in response to this thread on the CouchDB dev list: >> >>http://s.apache.org/HR9 > ... > > Thanks for the comments and focus on the thread; they are very helpful. I've > found that trademarks law often seems quite non-intuitive to programmers. We > typically see things in binary: it compiles or doesn't; it's faster or it's > slower. Trademarks are fundamentally about ensuring that an informed > consumer understands where their products are coming from based on the brand > name of the product. Thus, the perception of users - especially new ones to > this territory - are important to consider. > > As I understand it, fundamentally we had Apache CouchDB first, and then it's > quick popularity bred several other companies and software products with > names including the word "Couch" in them. The fact that both a number of > CouchDB committers and some normal end-users of CouchDB are expressing > confusion over some Couchbase software products means that this is an issue > we should seek to address, and is one that I hope Couchbase will actively > help to address to prevent confusion as to the source of Apache CouchDB > software. [Couchbase hat]: We are committed to help ensure that Apache CouchDB is a thriving success from the C-level down. To action behind words, we are helping to address the trademark concerns the best we can. > I have a number of general comments for the PMC: > > - The simplest and most direct step to take is to better tell our own story > of what Apache CouchDB is and how it can help new consumers run their servers > / data /business better, easier, and faster than other products. > > One key item would be improving the couchdb.a.o website, in particular so > that it better describes what CouchDB is and how to use it to *newcomers* to > the technology. Separately, I bet it would be helpful for committers (and > others) to blog and post about CouchDB individually, both to explain why > CouchDB is so great, and also to explain that there's only one Apache > CouchDB, and all the other Couches are less (or more) related to us, the > first Couch-named No-SQL db. [Apache CouchDB hat]: That's very good advice. For a while now I longed for a page that explains the CouchDB ecosystem in a nutshell. I have personally not gotten to it, but I'd love to see a page that is a brief introduction into all the players that make up the greater CouchDB ecosystem with Apache CouchDB at its centre. It could be as simple as starting with a list on our wiki. > - The number and detail of comments from both committers and users about > "which Couch is which" and "How is Couchbase related to CouchDB" say to me > that there is a branding issue here - hopefully one that we can work through > amicably and with assistance from Couchbase. > > To be frank, it's unlikely that we could prevent all other organizations from > using "Couch" in their names. However it is possible to take actions to > ensure that other organizations do not confuse informed consumers as to the > true source of Apache CouchDB software. [Couchbase hat]: Again, we're happy to do our part. > - When dealing with user confusion by a third party or even potential > trademark infringements by a third party, the first step is to figure out > what the PMC would like to see happen (you're doing this), and then to ask > nicely (usually in private, to allow people to save face if they want to) the > third party to make some changes. > > In this case, think that it's probably unrealistic to ask Couchbase to > completely rebrand themselves. There are several Couch-something products > out there, and it certainly seems (I'm guessing, I don't know) that they're > as attached to their overall name as we are to the CouchDB name. > > It is realistic - and we should! - ask them to respect our trademarks. They > can do this by being diligent at following our formal trademark policy, > especially by explicitly attributing our marks on any pages or materials > where they have products that are using similar names or descriptions. > > For example, it would be appropriate in this case to ask that they attribute > our CouchDB mark on their Couchbase server web pages, like this one: > > http://www.couchbase.com/couchbase-server/overview > > Similarly, given the history in this case, it would be realistic to ask them > to go further, and include explanatory text in various places on their > website that
RE: Fundamentals Question on CoucheDB's append only b+tree.
Thanks, That clears it all up, and makes more sense now. Owain -Original Message- From: Robert Newson [mailto:rnew...@apache.org] Sent: 13 March 2012 17:41 To: dev@couchdb.apache.org Subject: Re: Fundamentals Question on CoucheDB's append only b+tree. There's no linked list running between the leafs. A b+tree doesn't require one, though it's a common addition. The b+tree algorithm is a revision over a binary tree (where inner nodes point strictly at one left and one right item). To be a b+tree you need to hold many pointers on an inner node. B. On 13 March 2012 17:26, Davies, Owain wrote: > Hi, > > I have been reading the couchDB guide, particularly the appendix on > the power of b-trees. As I understand it couchdb uses a b+tree, in > which the leaf nodes have pointers to their siblings to facilitate > quick in-order and reverse in-order enumeration of the documents in the b+tree. > > When a document is modified (or added), then the document is appended > to the file, the leaf node is cloned and updated to point to the new > document. However in order to maintain the linked list between the > sibling leaf nodes, you would need to update the adjacent link nodes > (creating new leaf nodes appended onto the end of the file), this will > eventually require that the whole tree is replicated, not just the > node on the path to the effected leaf node. > > I do not think this can be the case, could somebody point out where I > have made the mistake? > > Thanks, > > Owain > > Please consider the environment before printing this email. > > This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. > > Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. > > The contents of this email may relate to dealings with other companies under the control of BAE Systems plc details of which can be found at http://www.baesystems.com/Businesses/index.htm. > > Detica Limited is a BAE Systems company trading as BAE Systems Detica. > Detica Limited is registered in England and Wales under No: 1337451. > Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. > Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems plc details of which can be found at http://www.baesystems.com/Businesses/index.htm. Detica Limited is a BAE Systems company trading as BAE Systems Detica. Detica Limited is registered in England and Wales under No: 1337451. Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
Re: Fundamentals Question on CoucheDB's append only b+tree.
There's no linked list running between the leafs. A b+tree doesn't require one, though it's a common addition. The b+tree algorithm is a revision over a binary tree (where inner nodes point strictly at one left and one right item). To be a b+tree you need to hold many pointers on an inner node. B. On 13 March 2012 17:26, Davies, Owain wrote: > Hi, > > I have been reading the couchDB guide, particularly the appendix on the > power of b-trees. As I understand it couchdb uses a b+tree, in which the > leaf nodes have pointers to their siblings to facilitate quick in-order > and reverse in-order enumeration of the documents in the b+tree. > > When a document is modified (or added), then the document is appended to > the file, the leaf node is cloned and updated to point to the new > document. However in order to maintain the linked list between the > sibling leaf nodes, you would need to update the adjacent link nodes > (creating new leaf nodes appended onto the end of the file), this will > eventually require that the whole tree is replicated, not just the node > on the path to the effected leaf node. > > I do not think this can be the case, could somebody point out where I > have made the mistake? > > Thanks, > > Owain > > Please consider the environment before printing this email. > > This message should be regarded as confidential. If you have received this > email in error please notify the sender and destroy it immediately. > > Statements of intent shall only become binding when confirmed in hard copy by > an authorised signatory. > > The contents of this email may relate to dealings with other companies under > the control of BAE Systems plc details of which can be found at > http://www.baesystems.com/Businesses/index.htm. > > Detica Limited is a BAE Systems company trading as BAE Systems Detica. > Detica Limited is registered in England and Wales under No: 1337451. > Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. >
Re: Fundamentals Question on CoucheDB's append only b+tree.
On Mar 13, 2012, at 1:26 PM, Davies, Owain wrote: > Hi, > > I have been reading the couchDB guide, particularly the appendix on the > power of b-trees. As I understand it couchdb uses a b+tree, in which the > leaf nodes have pointers to their siblings to facilitate quick in-order > and reverse in-order enumeration of the documents in the b+tree. > > When a document is modified (or added), then the document is appended to > the file, the leaf node is cloned and updated to point to the new > document. However in order to maintain the linked list between the > sibling leaf nodes, you would need to update the adjacent link nodes > (creating new leaf nodes appended onto the end of the file), this will > eventually require that the whole tree is replicated, not just the node > on the path to the effected leaf node. > > I do not think this can be the case, could somebody point out where I > have made the mistake? yes, the leaf nodes in couchdb are not linked > > Thanks, > > Owain > > Please consider the environment before printing this email. > > This message should be regarded as confidential. If you have received this > email in error please notify the sender and destroy it immediately. > > Statements of intent shall only become binding when confirmed in hard copy by > an authorised signatory. > > The contents of this email may relate to dealings with other companies under > the control of BAE Systems plc details of which can be found at > http://www.baesystems.com/Businesses/index.htm. > > Detica Limited is a BAE Systems company trading as BAE Systems Detica. > Detica Limited is registered in England and Wales under No: 1337451. > Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. >
Fundamentals Question on CoucheDB's append only b+tree.
Hi, I have been reading the couchDB guide, particularly the appendix on the power of b-trees. As I understand it couchdb uses a b+tree, in which the leaf nodes have pointers to their siblings to facilitate quick in-order and reverse in-order enumeration of the documents in the b+tree. When a document is modified (or added), then the document is appended to the file, the leaf node is cloned and updated to point to the new document. However in order to maintain the linked list between the sibling leaf nodes, you would need to update the adjacent link nodes (creating new leaf nodes appended onto the end of the file), this will eventually require that the whole tree is replicated, not just the node on the path to the effected leaf node. I do not think this can be the case, could somebody point out where I have made the mistake? Thanks, Owain Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems plc details of which can be found at http://www.baesystems.com/Businesses/index.htm. Detica Limited is a BAE Systems company trading as BAE Systems Detica. Detica Limited is registered in England and Wales under No: 1337451. Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
Enforced filter functions
So I was trying to implement the ability for logged in users to subscribe to the changes feed for updates to their own documents (its currently admin only), its a simple patch but its not very clean (mostly because the we dont want to have the changes feed read the full document) A way that I could implement it, that seems a lot more globally applicable and applies cleaner, is to allow the ddoc author to enforce filters to happen on non admin access to _changes and replication (on any database) This should negatively affect anything else, filters are already used and supported in both places, I have also seen it asked for regularly in the context of replication, ddoc authors could specify exactly what users are allowed to replicate, the enforced filter would override any users filter As far as I can tell the only problem would be how to have the author specify the enforcement, apart from that it should apply cleanly, introduces a fairly large amount of new functionality and adds very little overhead Ideas? Jan mentioned this could be used more widely for updates / shows / lists, that is starting to sound more complicated and does start introducing problems, I would prefer to look at the simple case of filters for changes / replication for now, but if there was an even more global solution that applied cleanly, I would be happy to
Re: Enforced filter functions
On 13 March 2012 15:30, Dale Harvey wrote: > So I was trying to implement the ability for logged in users to subscribe > to the changes feed for updates to their own documents (its currently admin > only), its a simple patch but its not very clean (mostly because the we > dont want to have the changes feed read the full document) > > A way that I could implement it, that seems a lot more globally applicable > and applies cleaner, is to allow the ddoc author to enforce filters to > happen on non admin access to _changes and replication (on any database) > > This should negatively affect anything else, filters are already used and > supported in both places, I have also seen it asked for regularly in the > context of replication, ddoc authors could specify exactly what users are > allowed to replicate, the enforced filter would override any users filter > > Obviously I meant "should not negatively affect" :) > As far as I can tell the only problem would be how to have the author > specify the enforcement, apart from that it should apply cleanly, > introduces a fairly large amount of new functionality and adds very little > overhead > > Ideas? > > Jan mentioned this could be used more widely for updates / shows / lists, > that is starting to sound more complicated and does start introducing > problems, I would prefer to look at the simple case of filters for changes > / replication for now, but if there was an even more global solution that > applied cleanly, I would be happy to > > >
[jira] [Updated] (COUCHDB-1439) `key`, `startkey`, `endkey` query parameters seems to have valid json value for show/update handlers.
[
https://issues.apache.org/jira/browse/COUCHDB-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-1439:
--
Attachment: couchdb-1439_tests.patch
Add patch with tests about this issue.
> `key`, `startkey`, `endkey` query parameters seems to have valid json value
> for show/update handlers.
> -
>
> Key: COUCHDB-1439
> URL: https://issues.apache.org/jira/browse/COUCHDB-1439
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Affects Versions: 1.2, 1.3
> Environment: Apache CouchDB 1.3.0a-d6ab08d-git
> Apache CouchDB 1.2.0a-0d8ddc8-git
>Reporter: Alexander Shorin
> Attachments: couchdb-1439_tests.patch
>
>
> CouchDB requires that values of query parameters with names: `key`,
> `startkey`, `endkey` be valid json value when request been catched by show or
> update handler. This behavior is expected for views and lists(as they works
> as proxy for views and views requires this values as valid json ones), but
> it's little surprising to see same behavior for shows and updates.
> It's easy to test with any show or update handler:
> ~ # curl -X PUT http://localhost:5984/app/_design/ddoc -d '{"shows":
> {"empty": "function(doc, req){return \"\"}"}, "updates": {"nothing":
> "function(doc, req){return [null, \"\"]}"}}'
> ~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=foo
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /app/_design/ddoc/_show/empty?key=foo HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 400 Bad Request
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Date: Tue, 13 Mar 2012 14:11:38 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 48
> < Cache-Control: must-revalidate
> <
> {"error":"bad_request","reason":"invalid_json"}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> curl -v -X POST http://localhost:5984/app/_design/ddoc/_update/nothing?key=foo
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > POST /app/_design/ddoc/_update/nothing?key=foo HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 400 Bad Request
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Date: Tue, 13 Mar 2012 15:14:11 GMT
> < Content-Type: text/plain; charset=utf-8
> < Content-Length: 48
> < Cache-Control: must-revalidate
> <
> {"error":"bad_request","reason":"invalid_json"}
> * Connection #0 to host localhost left intact
> * Closing connection #0
> while...
> ~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=%22foo%22
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1...
> * connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /app/_design/ddoc/_show/empty?key=%22foo%22 HTTP/1.1
> > User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Vary: Accept
> < Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
> < Etag: "3B14BLTA7M1G53XKHX7EP0JUO"
> < Date: Tue, 13 Mar 2012 14:12:20 GMT
> < Content-Type: application/json
> < Content-Length: 0
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
> Initially, I'd faced with such behavior only for `key` parameter. Digging
> deeper I've found[1] same thing for `startkey` and `endkey` parameters, but
> I've no idea how to explain their dependency well.
> [1]
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_httpd_external.erl;h=bfe77a329d569bcc48cb65d8251a437baf13fae6;hb=HEAD#l110
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1439) `key`, `startkey`, `endkey` query parameters seems to have valid json value for show/update handlers.
`key`, `startkey`, `endkey` query parameters seems to have valid json value for
show/update handlers.
-
Key: COUCHDB-1439
URL: https://issues.apache.org/jira/browse/COUCHDB-1439
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2, 1.3
Environment: Apache CouchDB 1.3.0a-d6ab08d-git
Apache CouchDB 1.2.0a-0d8ddc8-git
Reporter: Alexander Shorin
CouchDB requires that values of query parameters with names: `key`, `startkey`,
`endkey` be valid json value when request been catched by show or update
handler. This behavior is expected for views and lists(as they works as proxy
for views and views requires this values as valid json ones), but it's little
surprising to see same behavior for shows and updates.
It's easy to test with any show or update handler:
~ # curl -X PUT http://localhost:5984/app/_design/ddoc -d '{"shows": {"empty":
"function(doc, req){return \"\"}"}, "updates": {"nothing": "function(doc,
req){return [null, \"\"]}"}}'
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /app/_design/ddoc/_show/empty?key=foo HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Date: Tue, 13 Mar 2012 14:11:38 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 48
< Cache-Control: must-revalidate
<
{"error":"bad_request","reason":"invalid_json"}
* Connection #0 to host localhost left intact
* Closing connection #0
curl -v -X POST http://localhost:5984/app/_design/ddoc/_update/nothing?key=foo
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> POST /app/_design/ddoc/_update/nothing?key=foo HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Date: Tue, 13 Mar 2012 15:14:11 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 48
< Cache-Control: must-revalidate
<
{"error":"bad_request","reason":"invalid_json"}
* Connection #0 to host localhost left intact
* Closing connection #0
while...
~ # curl -v http://localhost:5984/app/_design/ddoc/_show/empty?key=%22foo%22
* About to connect() to localhost port 5984 (#0)
* Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 5984 (#0)
> GET /app/_design/ddoc/_show/empty?key=%22foo%22 HTTP/1.1
> User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 GnuTLS/2.10.5
> zlib/1.2.5
> Host: localhost:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Vary: Accept
< Server: CouchDB/1.3.0a-d6ab08d-git (Erlang OTP/R14B04)
< Etag: "3B14BLTA7M1G53XKHX7EP0JUO"
< Date: Tue, 13 Mar 2012 14:12:20 GMT
< Content-Type: application/json
< Content-Length: 0
<
* Connection #0 to host localhost left intact
* Closing connection #0
Initially, I'd faced with such behavior only for `key` parameter. Digging
deeper I've found[1] same thing for `startkey` and `endkey` parameters, but
I've no idea how to explain their dependency well.
[1]
http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=src/couchdb/couch_httpd_external.erl;h=bfe77a329d569bcc48cb65d8251a437baf13fae6;hb=HEAD#l110
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Couchbase trademark issues
I know I kicked this all off on dev a few weeks ago so I'd just like to say that from my perspective, as a developer using the product in production systems and trying to sell it to other clients as a suitable technology to use, Robert has it spot on. Roger On 13 March 2012 13:52, Robert Newson wrote: > I don't believe any CouchDB committer or PMC member has any interest > in changing the project name. > > I personally feel, as you do, that it's the other products that must > clearly distinguish themselves from CouchDB. The company and product > called "Couchbase" clearly confuses the community, who reasonably, but > erroneously, believe that it's related to CouchDB (the truth, now, is > that couchdb is an important but internal component). Sponsoring the > "CouchConf" conferences which talks about "Couch NoSQL technology" but > also "the Couchbase technology" is similarly confusing, especially as > "CouchConf"'s in the past were about Apache CouchDB and things > compatible or complementary to it. > > For my part, the ideal solution would be for Couchbase to rename its > product and conferences to not imply that they are about CouchDB, to > me that means not using the word 'couch'. I understand that the > trademark we hold is on 'Apache CouchDB' and that we cannot assert any > rights over the word 'couch', but I don't think anyone can deny that > confusion caused is real. Since the Couchbase product is not CouchDB > compatible it's surprising that it hasn't been rebranded for marketing > reasons already. > > B. > > On 13 March 2012 04:01, Shane Curcuru wrote: > > (Whoops! Apologies for mixed up subjects and poor threading; I'm not on > > dev@) > > > > I just wanted to add one other comment about this previous note: > > > > James Hayton wrote on Feb 20, 2012: > >> > >> Maybe a crazy idea, but since the end result of any legal stuff would > >> be somebody changing the name of something, why doesn't Apache > >> CouchDB just re brand itself? I mean we need a website makeover, > >> etc... Why don't we just ditch the name and come up with something > >> better with a new vision, new leadership, etc... Lets put a few > >> features in that people have been asking for, include the big couch > >> code (clustering), create a new website and call it something > >> different. (CouchDB 2.0 Becomes AwesomeDB lol) > >> > >> I understand that alot of people have quite a bit invested in the > >> name CouchDB, at this may not be something realistic, but this just > >> seems like at least another option we should discuss. > >> > >> Just my .02. > >> > >> James > > > > > > If the bulk of the Apache CouchDB PMC truly wanted to consider a rename > (and > > discussed and [VOTE]d on the matter, then we'd certainly help that to > > happen. The PMC *is* who gets to decide the project direction. > > > > But I'm confident that's *not* the case, since several folks have spoken > out > > against it. I personally think it would be a really bad idea to change > the > > CouchDB name - especially since CouchDB is arguably the first project > that > > gave such brand recognition to the "Couch" name in the noSQL database > arena. > > > > In most trademark issues, I'd think more people would ask why the > > *follow-on* products don't change their names, rather than the original > > product. But in this case, I'm hoping that the pain of renaming is not > > necessary, and we can reduce user confusion by both improving our own > story, > > as well as asking other Couch-named products to better differentiate > > themselves and better give us - this PMC, the committers, and the ASF - > the > > credit we deserve for building and shipping Apache CouchDB itself in the > > first place. > > > > - Shane > > >
Re: Couchbase trademark issues
I don't believe any CouchDB committer or PMC member has any interest in changing the project name. I personally feel, as you do, that it's the other products that must clearly distinguish themselves from CouchDB. The company and product called "Couchbase" clearly confuses the community, who reasonably, but erroneously, believe that it's related to CouchDB (the truth, now, is that couchdb is an important but internal component). Sponsoring the "CouchConf" conferences which talks about "Couch NoSQL technology" but also "the Couchbase technology" is similarly confusing, especially as "CouchConf"'s in the past were about Apache CouchDB and things compatible or complementary to it. For my part, the ideal solution would be for Couchbase to rename its product and conferences to not imply that they are about CouchDB, to me that means not using the word 'couch'. I understand that the trademark we hold is on 'Apache CouchDB' and that we cannot assert any rights over the word 'couch', but I don't think anyone can deny that confusion caused is real. Since the Couchbase product is not CouchDB compatible it's surprising that it hasn't been rebranded for marketing reasons already. B. On 13 March 2012 04:01, Shane Curcuru wrote: > (Whoops! Apologies for mixed up subjects and poor threading; I'm not on > dev@) > > I just wanted to add one other comment about this previous note: > > James Hayton wrote on Feb 20, 2012: >> >> Maybe a crazy idea, but since the end result of any legal stuff would >> be somebody changing the name of something, why doesn't Apache >> CouchDB just re brand itself? I mean we need a website makeover, >> etc... Why don't we just ditch the name and come up with something >> better with a new vision, new leadership, etc... Lets put a few >> features in that people have been asking for, include the big couch >> code (clustering), create a new website and call it something >> different. (CouchDB 2.0 Becomes AwesomeDB lol) >> >> I understand that alot of people have quite a bit invested in the >> name CouchDB, at this may not be something realistic, but this just >> seems like at least another option we should discuss. >> >> Just my .02. >> >> James > > > If the bulk of the Apache CouchDB PMC truly wanted to consider a rename (and > discussed and [VOTE]d on the matter, then we'd certainly help that to > happen. The PMC *is* who gets to decide the project direction. > > But I'm confident that's *not* the case, since several folks have spoken out > against it. I personally think it would be a really bad idea to change the > CouchDB name - especially since CouchDB is arguably the first project that > gave such brand recognition to the "Couch" name in the noSQL database arena. > > In most trademark issues, I'd think more people would ask why the > *follow-on* products don't change their names, rather than the original > product. But in this case, I'm hoping that the pain of renaming is not > necessary, and we can reduce user confusion by both improving our own story, > as well as asking other Couch-named products to better differentiate > themselves and better give us - this PMC, the committers, and the ASF - the > credit we deserve for building and shipping Apache CouchDB itself in the > first place. > > - Shane >
Re: Couchbase trademark issues
(Whoops! Apologies for mixed up subjects and poor threading; I'm not on dev@) I just wanted to add one other comment about this previous note: James Hayton wrote on Feb 20, 2012: Maybe a crazy idea, but since the end result of any legal stuff would be somebody changing the name of something, why doesn't Apache CouchDB just re brand itself? I mean we need a website makeover, etc... Why don't we just ditch the name and come up with something better with a new vision, new leadership, etc... Lets put a few features in that people have been asking for, include the big couch code (clustering), create a new website and call it something different. (CouchDB 2.0 Becomes AwesomeDB lol) I understand that alot of people have quite a bit invested in the name CouchDB, at this may not be something realistic, but this just seems like at least another option we should discuss. Just my .02. James If the bulk of the Apache CouchDB PMC truly wanted to consider a rename (and discussed and [VOTE]d on the matter, then we'd certainly help that to happen. The PMC *is* who gets to decide the project direction. But I'm confident that's *not* the case, since several folks have spoken out against it. I personally think it would be a really bad idea to change the CouchDB name - especially since CouchDB is arguably the first project that gave such brand recognition to the "Couch" name in the noSQL database arena. In most trademark issues, I'd think more people would ask why the *follow-on* products don't change their names, rather than the original product. But in this case, I'm hoping that the pain of renaming is not necessary, and we can reduce user confusion by both improving our own story, as well as asking other Couch-named products to better differentiate themselves and better give us - this PMC, the committers, and the ASF - the credit we deserve for building and shipping Apache CouchDB itself in the first place. - Shane
Re: Seeking CouchDB guidance
(Apologies for coming late to this thread; note I'm not on dev@) (cc: trademarks@ for FYI) On 2012-02-22 6:02 PM, Noah Slater wrote: Hello, I am reaching out to you in response to this thread on the CouchDB dev list: http://s.apache.org/HR9 ... Thanks for the comments and focus on the thread; they are very helpful. I've found that trademarks law often seems quite non-intuitive to programmers. We typically see things in binary: it compiles or doesn't; it's faster or it's slower. Trademarks are fundamentally about ensuring that an informed consumer understands where their products are coming from based on the brand name of the product. Thus, the perception of users - especially new ones to this territory - are important to consider. As I understand it, fundamentally we had Apache CouchDB first, and then it's quick popularity bred several other companies and software products with names including the word "Couch" in them. The fact that both a number of CouchDB committers and some normal end-users of CouchDB are expressing confusion over some Couchbase software products means that this is an issue we should seek to address, and is one that I hope Couchbase will actively help to address to prevent confusion as to the source of Apache CouchDB software. I have a number of general comments for the PMC: - The simplest and most direct step to take is to better tell our own story of what Apache CouchDB is and how it can help new consumers run their servers / data /business better, easier, and faster than other products. One key item would be improving the couchdb.a.o website, in particular so that it better describes what CouchDB is and how to use it to *newcomers* to the technology. Separately, I bet it would be helpful for committers (and others) to blog and post about CouchDB individually, both to explain why CouchDB is so great, and also to explain that there's only one Apache CouchDB, and all the other Couches are less (or more) related to us, the first Couch-named No-SQL db. - The number and detail of comments from both committers and users about "which Couch is which" and "How is Couchbase related to CouchDB" say to me that there is a branding issue here - hopefully one that we can work through amicably and with assistance from Couchbase. To be frank, it's unlikely that we could prevent all other organizations from using "Couch" in their names. However it is possible to take actions to ensure that other organizations do not confuse informed consumers as to the true source of Apache CouchDB software. - When dealing with user confusion by a third party or even potential trademark infringements by a third party, the first step is to figure out what the PMC would like to see happen (you're doing this), and then to ask nicely (usually in private, to allow people to save face if they want to) the third party to make some changes. In this case, think that it's probably unrealistic to ask Couchbase to completely rebrand themselves. There are several Couch-something products out there, and it certainly seems (I'm guessing, I don't know) that they're as attached to their overall name as we are to the CouchDB name. It is realistic - and we should! - ask them to respect our trademarks. They can do this by being diligent at following our formal trademark policy, especially by explicitly attributing our marks on any pages or materials where they have products that are using similar names or descriptions. For example, it would be appropriate in this case to ask that they attribute our CouchDB mark on their Couchbase server web pages, like this one: http://www.couchbase.com/couchbase-server/overview Similarly, given the history in this case, it would be realistic to ask them to go further, and include explanatory text in various places on their website that explain what CouchDB is, that it comes from Apache, and that their product is not related to CouchDB (either in technical compatibility, or in terms of governance/provenance). The web page they put up at http://www.couchbase.com/couchdb is an excellent start to this, and is very much appreciated - thanks! However it would be realistic - especially in the short term - to ask for some other explicit mentions of what CouchDB is in some places on their website that are closer to their actual Couchbase-named product pages. I.e. it would be great if they'd put a small one-paragraph "Couchbase SuperThing And Apache CouchDB - to great (but separate) things...", perhaps with a link to their /couchbdb page. Trademarks are about preventing user confusion over the source of products (in these cases, primarily software downloads). Especially given that the ASF is a community-oriented non-profit, there are plenty of ways that third parties can do an aggressive job of marketing their own product(s), while still providing plenty of credit and links back to Apache project pages, recog
[jira] [Created] (COUCHDB-1438) GET /// triggers a 500 error
GET /// triggers a 500 error
Key: COUCHDB-1438
URL: https://issues.apache.org/jira/browse/COUCHDB-1438
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.2
Reporter: Jason Smith
Assignee: Jason Smith
Priority: Minor
I just noticed this.
$ curl -i http://localhost:5984//
HTTP/1.1 500 Internal Server Error
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Date: Tue, 13 Mar 2012 08:48:46 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 53
Cache-Control: must-revalidate
{"error":"unknown_error","reason":"function_clause"}
That's weird. Usually CouchDB strips trailing slashes:
$ curl http://localhost:5984/x/
{"db_name":"x","doc_count":1,...}
$ curl http://localhost:5984/x/blah/
{"_id":"blah","_rev":"2-6c4b3bc6c2fdc5043139942dc6f1b994","_attachments":{"out.txt"
...
$ curl http://localhost:5984/x/blahout.txt///
Hello, world!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
