You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2009/03/24 15:00:50 UTC
[VOTE] Apache CouchDB 0.9.0 release
Hello,
This is the first release after graduating the ASF Incubator.
All 0.9.0 blockers have been resolved and I would like call a vote for release.
We encourage the whole community to download and test these release artifacts so
that any critical issues can be resolved before the release is made. Everyone is
free to vote on this release, so get stuck in!
We are voting on the following release artifacts:
http://people.apache.org/~nslater/dist/0.9.0/
These artifacts have been built from the 0.9.0 tag in Subversion:
http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
Happy voting,
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Noah Slater <ns...@apache.org>.
+1
Tested on Debian unstable.
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Mar 2009, at 17:17, Noah Slater wrote:
> Hello,
>
> A few small issues have been fixed with the 0.9.0 release.
>
> I have prepared new artifacts and you can access them at the
> original location.
>
> Happy voting,
+1
(Tested on Ubuntu, CentOS, Mac OS X Leopard, tests pass, signatures
match).
Great job everybody!
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Brian Candler <B....@pobox.com>.
On Tue, Mar 24, 2009 at 11:31:32AM -0500, Zachary Zolton wrote:
> To any Ubuntu users, are you all still just downloading the Erlang
> source from erlang.org, or is there a pre-compiled binary available
> somehow?
I am using Ubuntu Hardy, but with the Erlang packages from Intrepid, using
the instructions at http://wiki.reia-lang.org/wiki/Installing_Erlang_on_Ubuntu
Just make a temporary change to your /etc/apt/sources.list, install Erlang,
then apt-get install the packages, then put it back again.
Here's what I have:
$ dpkg-query -l | grep erlang
ii erlang 1:12.b.3-dfsg-1ubuntu1 Concurrent, real-time, distributed functiona
ii erlang-base 1:12.b.3-dfsg-1ubuntu1 Concurrent, real-time, distributed functiona
ii erlang-dev 1:12.b.3-dfsg-1ubuntu1 Concurrent, real-time, distributed functiona
ii erlang-doc-html 1:12.b.3-dfsg-1 Erlang HTML pages
ii erlang-manpages 1:12.b.3-1 Erlang man pages
ii erlang-nox 1:12.b.3-dfsg-1ubuntu1 Concurrent, real-time, distributed functiona
ii erlang-x11 1:12.b.3-dfsg-1ubuntu1 Concurrent, real-time, distributed functiona
Cheers,
Brian.
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Zachary Zolton <za...@gmail.com>.
I'm currently using 8.04 (cuz it's the LTS), but may consider the switch…
Thanks for the tip!
On Tue, Mar 24, 2009 at 11:34 AM, Jason Smith
<jh...@proven-corporation.com> wrote:
> Zachary Zolton wrote:
>>
>> To any Ubuntu users, are you all still just downloading the Erlang
>> source from erlang.org, or is there a pre-compiled binary available
>> somehow?
>
> At least Intrepid (8.10) has Erlang packages built into the default repo.
> The EC2 wiki page is in actuality a long Ubuntu Intrepid walkthrough so you
> may find starting from step 4 useful.
>
> http://wiki.apache.org/couchdb/Getting_started_with_Amazon_EC2
>
> --
> Jason Smith
> Proven Corporation
> Bangkok, Thailand
> http://www.proven-corporation.com
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Jason Smith <jh...@proven-corporation.com>.
Zachary Zolton wrote:
> To any Ubuntu users, are you all still just downloading the Erlang
> source from erlang.org, or is there a pre-compiled binary available
> somehow?
At least Intrepid (8.10) has Erlang packages built into the default
repo. The EC2 wiki page is in actuality a long Ubuntu Intrepid
walkthrough so you may find starting from step 4 useful.
http://wiki.apache.org/couchdb/Getting_started_with_Amazon_EC2
--
Jason Smith
Proven Corporation
Bangkok, Thailand
http://www.proven-corporation.com
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Zachary Zolton <za...@gmail.com>.
To any Ubuntu users, are you all still just downloading the Erlang
source from erlang.org, or is there a pre-compiled binary available
somehow?
On Tue, Mar 24, 2009 at 11:17 AM, Noah Slater <ns...@apache.org> wrote:
> Hello,
>
> A few small issues have been fixed with the 0.9.0 release.
>
> I have prepared new artifacts and you can access them at the original location.
>
> Happy voting,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Paul Carey <pa...@gmail.com>.
> Happy voting,
>
> --
> Noah Slater, http://tumbolia.org/nslater
+1
All green from the RelaxDB test suite except for CouchDB-292 which is
fix for 0.10.
Paul
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Noah Slater <ns...@apache.org>.
Hello,
A few small issues have been fixed with the 0.9.0 release.
I have prepared new artifacts and you can access them at the original location.
Happy voting,
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Mark Gallop <ma...@gmail.com>.
On 24/3/09 11:00 PM, Noah Slater wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
+1
OS X Leopard is passing all the tests for me.
Cheers,
Mark
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Jason Davies <ja...@jasondavies.com>.
Hello,
On 24 Mar 2009, at 14:00, Noah Slater wrote:
> All 0.9.0 blockers have been resolved and I would like call a vote
> for release.
>
> We encourage the whole community to download and test these release
> artifacts so
> that any critical issues can be resolved before the release is made.
> Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
+1
Tested in Mac OS X Leopard and I've been running trunk on my live
setup on Debian for a few days now with no problems.
--
Jason Davies
www.jasondavies.com
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Chris Anderson <jc...@apache.org>.
On Tue, Mar 24, 2009 at 2:00 PM, Noah Slater <ns...@apache.org> wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
+1 works for me and is deployed on jchrisa.net successfully as well.
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Rob Evans <ob...@gmail.com>.
On Tue, Mar 24, 2009 at 11:00 AM, Noah Slater <ns...@apache.org> wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
Grabbed the latest-latest and it builds and runs fine for me on Mac OS
X Build 9G55. The objective-c library I maintain seems to be happy as
well.
Minor data point:
My build of Safari (Version 4 Public Beta 5528.16 ) fails
intermittently when running the test suite[1,2]. Firefox 3.0.7, on the
other hand, runs the tests just fine. Clearly a webkit issue and not
CouchDB related. So...
+1
[1] http://www.quicksnapper.com/objectiveous/full/untitled-0008/
[2] http://www.quicksnapper.com/objectiveous/full/untitled-0009/
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Ben Browning <be...@gmail.com>.
+1 for 0.9 release - The current trunk is a huge step forward from the
last release.
Ben
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Noah Slater <ns...@apache.org>.
On Fri, Mar 27, 2009 at 05:34:06PM -0500, Zachary Zolton wrote:
> So… Did we actually release 0.9?
No, I have to call the results, release, then announce. Stay tuned.
Bonus points for using a horizontal ellipsis! Heh.
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Zachary Zolton <za...@gmail.com>.
So… Did we actually release 0.9?
On Thu, Mar 26, 2009 at 6:19 AM, Wojciech Kaczmarek
<ka...@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 11:46, Wojciech Kaczmarek <ka...@gmail.com> wrote:
>> First time posting here, I've been a lurker for a couple of weeks.
>>
>> I have Mac OS X 10.4.11 PPC, Erlang 12B-5
>> 'stats' test fails:
>> Assertion 'open_databases > 0 && max >= open_databases, name' failed:
>> should keep the same number of open databases when reaching the
>> max_dbs_open limit
>>
>> I just did fresh make install into a separate location, not messing
>> with any previous installations.
>
> Actually, I'm able to replicate this error only if I run couchdb as
> root, which I did by mistake. Running as a dedicated user passes all
> tests.
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Wojciech Kaczmarek <ka...@gmail.com>.
On Thu, Mar 26, 2009 at 11:46, Wojciech Kaczmarek <ka...@gmail.com> wrote:
> First time posting here, I've been a lurker for a couple of weeks.
>
> I have Mac OS X 10.4.11 PPC, Erlang 12B-5
> 'stats' test fails:
> Assertion 'open_databases > 0 && max >= open_databases, name' failed:
> should keep the same number of open databases when reaching the
> max_dbs_open limit
>
> I just did fresh make install into a separate location, not messing
> with any previous installations.
Actually, I'm able to replicate this error only if I run couchdb as
root, which I did by mistake. Running as a dedicated user passes all
tests.
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Wojciech Kaczmarek <ka...@gmail.com>.
Hi!
First time posting here, I've been a lurker for a couple of weeks.
I have Mac OS X 10.4.11 PPC, Erlang 12B-5
'stats' test fails:
Assertion 'open_databases > 0 && max >= open_databases, name' failed:
should keep the same number of open databases when reaching the
max_dbs_open limit
I just did fresh make install into a separate location, not messing
with any previous installations.
cheers
Wojtek
> On 24.03.2009, at 15:00, Noah Slater wrote:
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>>
>> We encourage the whole community to download and test these release artifacts so
>> that any critical issues can be resolved before the release is made. Everyone is
>> free to vote on this release, so get stuck in!
>>
>> We are voting on the following release artifacts:
>>
>> http://people.apache.org/~nslater/dist/0.9.0/
>>
>> These artifacts have been built from the 0.9.0 tag in Subversion:
>>
>> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> +1
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Christopher Lenz <cm...@gmx.de>.
On 24.03.2009, at 15:00, Noah Slater wrote:
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote
> for release.
>
> We encourage the whole community to download and test these release
> artifacts so
> that any critical issues can be resolved before the release is made.
> Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
+1
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Volker Mische <vo...@gmail.com>.
Noah Slater wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
+1
Trunk works for me on Debian testing (64-bit). All tests in Futon pass
(Iceweasel 3.0.7).
Cheers,
Volker
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Sven Helmberger <sv...@gmx.de>.
Jan Lehnardt schrieb:
>
> Yes, 0.9 is not an API-freeze release. Although we planned for it, it
> was not
> feasible to hold back the release any longer in favour of a fixed API
> which is
> why a future pre 1.0 version will get the feature freeze. I think this is a
> useful feature and we should have it for at least 1.0 if not earlier.
>
> (Patches welcome :)
>
In general I am more than willing to help out but on the other hand I
don't speak erlang (yet?) and I'm too busy at my day job to really put
in the necessary hours.. jcouchdb is already stretching my limits..
Regards,
Sven Helmberger
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Jan Lehnardt <ja...@apache.org>.
On 25 Mar 2009, at 09:48, Sven Helmberger wrote:
> Noah Slater schrieb:
>> Hello,
>> This is the first release after graduating the ASF Incubator.
>> All 0.9.0 blockers have been resolved and I would like call a vote
>> for release.
>> We encourage the whole community to download and test these release
>> artifacts so
>> that any critical issues can be resolved before the release is
>> made. Everyone is
>> free to vote on this release, so get stuck in!
>> We are voting on the following release artifacts:
>> http://people.apache.org/~nslater/dist/0.9.0/
>> These artifacts have been built from the 0.9.0 tag in Subversion:
>> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>> Happy voting,
>
> What's up with tickets like
>
> https://issues.apache.org/jira/browse/COUCHDB-217
>
> are they effectively dead now or are we accepting additional format
> breakage after 0.9 now?
Yes, 0.9 is not an API-freeze release. Although we planned for it, it
was not
feasible to hold back the release any longer in favour of a fixed API
which is
why a future pre 1.0 version will get the feature freeze. I think this
is a
useful feature and we should have it for at least 1.0 if not earlier.
(Patches welcome :)
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Sven Helmberger <sv...@gmx.de>.
Noah Slater schrieb:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
What's up with tickets like
https://issues.apache.org/jira/browse/COUCHDB-217
are they effectively dead now or are we accepting additional format
breakage after 0.9 now?
Regards,
Sven Helmberger
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Noah Slater <ns...@apache.org>.
On Tue, Mar 24, 2009 at 02:00:50PM +0000, Noah Slater wrote:
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
A few issues have been spotted already, please stand by for an update.
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Mar 25, 2009 at 12:14 AM, Tim Parkin <in...@timparkin.co.uk> wrote:
> Noah Slater wrote:
>>
>> Hello,
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote for
>> release.
>>
>> We encourage the whole community to download and test these release
>> artifacts so
>> that any critical issues can be resolved before the release is made.
>> Everyone is
>> free to vote on this release, so get stuck in!
>
> I'd be interested in knowing what happened to the community discussion
> around the removal of the bulk_docs 'feature'? I've tried to raise this a
> couple of times but had little reaction. Am I right in understanding this
> lack of reaction as meaning there is going to be no discussion?
We've been concentrating on bulk docs documentation. In my experience,
most people who understand that the unit of consistency is the
document start to see ways of solving problems that work in a
key/value world. Some use-cases don't fit, but for the 80% case we're
better off with the simpler consistency model.
I'm working hard to make it easy for transactional conflict detection
to develop outside the core project. If it is in demand by many users,
comparison with the default consistency model will be worthwhile.
Damien has said he could see adding the feature back if people want it
and there's a good implementation.
I've moved the Bulk Docs API information to its own page:
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>
> As some fairly serious issues have been raised about user interaction models
> I would hope that these would get addressed before commiting to a point
> release?
>
I think the general understanding is that CouchDB is built with a
certain minimalist simplicity in mind. We appreciate that some of our
users have demands that exceed our out-of-the-box functionality. I
think once we have a solid understanding of how to use CouchDB in a
distributed manner, we'll be on steady footing for more ambitious
consistency guarantees.
Chris
--
Chris Anderson jchrisa.net couch.io
Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Posted by David Pratt <fa...@gmail.com>.
Hi. I am equally concerned about the issue Tim has raised. I am
disappointed because I was also counting on the functionality that
couch possessed going forward. We are loosing something here, though
it may not appear on the surface as being that important (possibly
because the apps with this use case in mind might be in the
minority). Despite this, it is difficult to accept the recent change
as a new limitation on current and future couch app development. I am
really hoping that this can be resolved in some way to accommodate
such scenarios as Tim has spent his effort describing. Forking couch
makes no sense to me at all. Many thanks.
Regards,
David
On 25-Mar-09, at 9:50 AM, Tim Parkin wrote:
>
> The upshot appears to be that CouchDB is limited to only changing a
> single document at a time through a user interface (unless you want to
> add lots of work to handle conflicts).. Could I have a confirmation of
> this so I can blog about it. It's a pretty fundamental restriction and
> one I'm sure people who want to use CouchDB would want to know about.
>
> Tim
>
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Jason Smith <jh...@proven-corporation.com>.
Tim Parkin wrote:
> The upshot appears to be that CouchDB is limited to only changing a
> single document at a time through a user interface (unless you want to
> add lots of work to handle conflicts).. Could I have a confirmation of
> this so I can blog about it. It's a pretty fundamental restriction and
> one I'm sure people who want to use CouchDB would want to know about.
I'm just a CouchDB user, not remotely affiliated with the project; but
as I said before:
1. We should move this to user@
2. Atomic activity is at the single document level. If the data has
relations then you may need to add lots of work to handle conflicts.
That is a fundamental restriction, one which people who want to use
CouchDB would want to know.
IMO the documentation and the book and the buzz indicate this, and God
knows if you spend any time writing an application, it becomes
immediately obvious. Not to mention that it should be apparent to a
developer that you will have to write more application code when you can
no longer just lock everything in sight, have a party with your data,
and then unlock whenever is convenient. I am interested in CouchDB
despite all those for two reasons:
1. Some applications don't need a relational model. For example,
revision control or wikis fit CouchDB well because they are mostly
append-only applications, and there is very little conflict resolution
logic (you outsource that to the users).
2. If you want to scale up and you choose CouchDB or a similar tool,
at least you are going into things with your eyes open. You admit that,
yes, it will take more work up front to build up the data-handling code,
but it pays off down the road when you can scale out.
So in short: yes, but it's worth the trade-off for some applications.
--
Jason Smith
Proven Corporation
Bangkok, Thailand
http://www.proven-corporation.com
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Damien Katz wrote:
> Can you put your use case on the wiki? It would be helpful to start a
> page about transaction use cases and where they are appropriate and the
> downsides of using them. I'm thinking add something to describes you use
> case and how it works (or doesn't work) with the current model, and also
> the conflict checking transaction model. We might figure out new
> solutions, tweaked models, etc that work better, or we might see the
> pressing need for the transaction style.
>
> -Damien
>
Thanks Damien,
Really appreciate the response.. I'll get stuff written up and have
something the wiki for Monday..
Cheers
tim
Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Posted by Damien Katz <da...@apache.org>.
Can you put your use case on the wiki? It would be helpful to start a
page about transaction use cases and where they are appropriate and
the downsides of using them. I'm thinking add something to describes
you use case and how it works (or doesn't work) with the current
model, and also the conflict checking transaction model. We might
figure out new solutions, tweaked models, etc that work better, or we
might see the pressing need for the transaction style.
-Damien
On Mar 25, 2009, at 4:52 PM, Tim Parkin wrote:
> Damien Katz wrote:
>
>> You could help by updating the wiki documentation to make this
>> clearer.
>> Multiple places if necessary.
>>
>
> Hi Damien,
>
> Could you help by taking a look at the issue I'm trying to work
> around.
> I'd love to work out a way of dealing with this without having to
> patch
> CouchDB (which is not what I want to do at all). I just think it's an
> important issues..
>
> Let me know if you want me to summarise it.
>
> Cheers
>
> Tim
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Damien Katz wrote:
> You could help by updating the wiki documentation to make this clearer.
> Multiple places if necessary.
>
Hi Damien,
Could you help by taking a look at the issue I'm trying to work around.
I'd love to work out a way of dealing with this without having to patch
CouchDB (which is not what I want to do at all). I just think it's an
important issues..
Let me know if you want me to summarise it.
Cheers
Tim
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Brian Candler <B....@pobox.com>.
On Wed, Apr 01, 2009 at 09:05:37AM +1030, Antony Blakey wrote:
>
> On 31/03/2009, at 11:14 PM, Brian Candler wrote:
>
>> Perhaps you want some sort of lock manager, whereby a client can
>> request a
>> lock on a group of documents, perform an update, then release the
>> lock?
>
> Then you need deadlock detection due to ordering of lock acquisition.
> Better to use the higher level concept of an atomic _bulk_docs.
Yeah, but CouchDB [TM] doesn't have that, so I'm suggesting an alternative.
There are plenty of simple algorithms to avoid lock ordering problems. If I
remember correctly, I think that just sorting the doc_ids you're interested
in and grabbing them in ascending order should be sufficient.
Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Posted by Antony Blakey <an...@gmail.com>.
On 31/03/2009, at 11:14 PM, Brian Candler wrote:
> Perhaps you want some sort of lock manager, whereby a client can
> request a
> lock on a group of documents, perform an update, then release the
> lock?
Then you need deadlock detection due to ordering of lock acquisition.
Better to use the higher level concept of an atomic _bulk_docs.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Nothing is really work unless you would rather be doing something else.
-- J. M. Barre
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Brian Candler <B....@pobox.com>.
On Mon, Mar 30, 2009 at 12:08:31PM +0100, Tim Parkin wrote:
> We do want to guarantee a rollback, is there a way to do this without
> atomic changes?
No that I can think of, for the reason given before (a non-atomic change by
definition gives an opportunity for another client to modify your work
before it is complete)
Perhaps you want some sort of lock manager, whereby a client can request a
lock on a group of documents, perform an update, then release the lock?
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Brian Candler wrote:
> On Fri, Mar 27, 2009 at 08:36:05PM +0000, Tim Parkin wrote:
>> Yes.. but we're not trying to guarantee consistency, just trying to
>> prevent inconsistency where possible
>
> In that case, I'm afraid I don't really understand what the goals are. Do
> you want to be able to guarantee a rollback, or not? If you don't care about
> rollback always being successful, then you can just PUT back the old
> documents.
>
Yes you are right.. we would like to be able to close the chance for
conflicts in a local database whilst dealing with conflicts caused by
replication.
We've come up with a few scenarios that limit the chance of conflicts
but the only scenario that removes it is atomic changes (as far as we
can tell - although because we're not sure we aren't saying we need
atomic changes , just that we need to close the chance for conflicts on
local changes).
Just replacing the documents leaves opportunity for someone else to grab
the documents before they are removed. We've tried using some form of
transactional change using markers but this is quite complicated and
still leaves a window of opportunity for *local* inconsistency.
We do want to guarantee a rollback, is there a way to do this without
atomic changes? If there isn't then, yes, we will probably need some
form of atomic change.
Tim
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Brian Candler <B....@pobox.com>.
On Fri, Mar 27, 2009 at 08:36:05PM +0000, Tim Parkin wrote:
> Yes.. but we're not trying to guarantee consistency, just trying to
> prevent inconsistency where possible
In that case, I'm afraid I don't really understand what the goals are. Do
you want to be able to guarantee a rollback, or not? If you don't care about
rollback always being successful, then you can just PUT back the old
documents.
> At the moment bulk docs are guaranteed atomic if the application crashes
> or validation fails (is this right?).. it's only if there is a conflict
> that atomicity has been made unavailable.
By "at the moment" do you mean current 0.9.0 semantics?
As I understand it there are two versions.
- normal _bulk_docs is not atomic. It is no different do just doing a
series of PUT operations one after the other, but at a lower HTTP
overhead. Concurrency control will reject an update if the supplied
_rev differs from the current one.
- _bulk_docs with "all_or_nothing":true *is* atomic. However it doesn't
perform concurrency control, but instead will add conflicting versions
of a document (same as if you added them to a different node, and then
replicated them back to the node in question)
B.
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Brian Candler wrote:
> On Thu, Mar 26, 2009 at 05:00:22PM +0000, Tim Parkin wrote:
>>> In what way is that not atomicity?
>> Well the difference is I'm more interested the ability to rollback than
>> the atomicity.
>
> But won't you need atomicity to guarantee the ability to rollback?
Yes.. but we're not trying to guarantee consistency, just trying to
prevent inconsistency where possible
>
> Consider the following sequence where I want to apply changes to A and B,
> but B fails.
>
> 1. Update A to A'
> 2. Try to update B to B' but it fails
> 3. Revert A' to A
>
> Now, what happens if someone else updates A in the middle?
>
> 1. Update A to A'
> 2. Another user updates A' to A"
> 3. Try to update B to B' but it fails
> 4. Err, what do I do now?
>
> I can't revert A" to A because that would also undo someone else's changes.
>
> At best, it could be handled like a replication conflict: both A and A"
> exist in the database simultaneously. However, the person making the update
> in (2) saw it as a successful, non-conflicting update.
>
Yes..
> The next person to read A will (if they ask) see two different versions. A'
> will have vanished if the database has been compacted, making it hard to
> resolve them back into one version.
>
> You also need to consider what happens when either the database or your
> application crashes in the middle of such a sequence. Unless your
> application maintains a separate transaction log, you would require the
> partial update to be rolled back by the database itself.
At the moment bulk docs are guaranteed atomic if the application crashes
or validation fails (is this right?).. it's only if there is a conflict
that atomicity has been made unavailable.
>
> In order to make sense of this, can I just step back a bit and work out
> exactly under what circumstances you need to roll back the transaction.
>
> Is your primary concern concurrency failure? That is, you tried to update B
> to B', but someone else had changed B to B" in the mean time?
>
> That's fine, but remember that concurrency control only works in the context
> of a single node anyway. A PUT will guarantee that my update from B to B' is
> not stomped on by someone else on the same node trying to update B to B".
> However, as soon as you introduce replication into the mix, all bets are
> off; you *will* get multiple conflicting versions in the database anyway.
>
Absolutely agree.. However just because we don't have a guarantee of
consistency doesn't mean we shouldn't be looking to increase the
occurence and probability of consistency. i.e. accidents happens but
that doesn't mean you shouldn't be careful..
> In essence I agree with you though: operations which are only atomic on a
> single node are useful (and that includes PUT concurrency control). Not
> everyone has a cluster or plans to go there.
>
> I also think the reason given on the wiki for dropping _bulk_docs atomic
> operations doesn't make sense. The old behaviour won't work on a sharded
> cluster without two-phase commit. But as far as I can see, the replacement
> "all_or_nothing" mode won't work on a sharded cluster without two-phase
> commit either.
>
That is my understanding also.. trying to make a single node look like a
distributed system is not feasible. However I'm hoping that some
compromise is possible and discussion is far from over.
> Of course, what's written on the wiki doesn't necessarily represent the
> views of the authors, who probably have a better reason for including this
> behaviour.
>
I'll be adding to the wiki next week just to increase the entropy :-)
Tim
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Brian Candler <B....@pobox.com>.
On Thu, Mar 26, 2009 at 05:00:22PM +0000, Tim Parkin wrote:
> > In what way is that not atomicity?
>
> Well the difference is I'm more interested the ability to rollback than
> the atomicity.
But won't you need atomicity to guarantee the ability to rollback?
Consider the following sequence where I want to apply changes to A and B,
but B fails.
1. Update A to A'
2. Try to update B to B' but it fails
3. Revert A' to A
Now, what happens if someone else updates A in the middle?
1. Update A to A'
2. Another user updates A' to A"
3. Try to update B to B' but it fails
4. Err, what do I do now?
I can't revert A" to A because that would also undo someone else's changes.
At best, it could be handled like a replication conflict: both A and A"
exist in the database simultaneously. However, the person making the update
in (2) saw it as a successful, non-conflicting update.
The next person to read A will (if they ask) see two different versions. A'
will have vanished if the database has been compacted, making it hard to
resolve them back into one version.
You also need to consider what happens when either the database or your
application crashes in the middle of such a sequence. Unless your
application maintains a separate transaction log, you would require the
partial update to be rolled back by the database itself.
In order to make sense of this, can I just step back a bit and work out
exactly under what circumstances you need to roll back the transaction.
Is your primary concern concurrency failure? That is, you tried to update B
to B', but someone else had changed B to B" in the mean time?
That's fine, but remember that concurrency control only works in the context
of a single node anyway. A PUT will guarantee that my update from B to B' is
not stomped on by someone else on the same node trying to update B to B".
However, as soon as you introduce replication into the mix, all bets are
off; you *will* get multiple conflicting versions in the database anyway.
In essence I agree with you though: operations which are only atomic on a
single node are useful (and that includes PUT concurrency control). Not
everyone has a cluster or plans to go there.
I also think the reason given on the wiki for dropping _bulk_docs atomic
operations doesn't make sense. The old behaviour won't work on a sharded
cluster without two-phase commit. But as far as I can see, the replacement
"all_or_nothing" mode won't work on a sharded cluster without two-phase
commit either.
Of course, what's written on the wiki doesn't necessarily represent the
views of the authors, who probably have a better reason for including this
behaviour.
Regards,
Brian.
Re: Restricting user interactions to a single document - PATCH
Posted by Antony Blakey <an...@gmail.com>.
On 27/03/2009, at 9:37 AM, Antony Blakey wrote:
> It seems the m/l is eating the patch attachment. Here is a gist: http://gist.github.com/86434
And now at: http://github.com/AntonyBlakey/couchdb/commit/3e831884367a49d723a9035f8fed1a0f0ed498ba
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Some defeats are instalments to victory.
-- Jacob Riis
Re: Restricting user interactions to a single document - PATCH
Posted by Antony Blakey <an...@gmail.com>.
It seems the m/l is eating the patch attachment. Here is a gist: http://gist.github.com/86434
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Isn't it enough to see that a garden is beautiful without having to
believe that there are fairies at the bottom of it too?
-- Douglas Adams
Re: Restricting user interactions to a single document - PATCH
Posted by Antony Blakey <an...@gmail.com>.
Attached is my first attempt at a minimal patch to re-enable fail-on-
conflict semantics for bulk_docs. My goal was to have the smallest
possible diff that can be maintained whilst tracking HEAD, rather than
the cleanest or best way to achieve the functionality. It's had
minimal testing - basically the following rake task using Couchrest
works differently depending on whether you put the fail_on_conflct =>
true into the second _bulk_docs:
require 'rubygems'
require 'couchrest'
desc "Test bulk docs conflicts"
task :bulk_docs do |t|
CouchRest.delete("http://localhost:5984/test") rescue nil
db = CouchRest.database!("http://localhost:5984/test")
d1 = { '_id' => '1', :version => 1 }
d2 = { '_id' => '2', :version => 1 }
r1 = db.save_doc(d1)
r2 = db.save_doc(d2)
d1[:version] = 2
d1['_rev'] = r1['rev']
d2[:version] = 2
d2['_rev'] = r2['rev']
br = db.bulk_save([d1, d2])
STDOUT.puts br.to_json
STDOUT.flush
d1[:version] = 3
d1['_rev'] = br[0]['rev']
d2[:version] = 3
br = CouchRest.post("http://localhost:5984/test/_bulk_docs",
{ :fail_on_conflict => true, :docs => [d1, d2]}) rescue {}
STDOUT.puts br.to_json
STDOUT.puts db.get('1').to_json
STDOUT.puts db.get('2').to_json
STDOUT.flush
end
On 27/03/2009, at 3:30 AM, Tim Parkin wrote:
> Antony Blakey wrote:
>> I have a patch that adds/restores fail-on-conflict bulk update
>> behaviour
>> (ie. your rollback requirement, but with no intermediate state). It's
>> 10-15 lines depending on formatting, i.e. fairly trivial, so it
>> should
>> be easy to keep it on HEAD. I trigger it explicitly by adding
>> fail-on-conflict: true to the top level json in the bulk request,
>> which
>> means that existing tests pass because the default semantics are
>> unpatched.
>>
>
> I'd be very interested - could I have a play with it?
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Chris Anderson <jc...@apache.org>.
On Thu, Mar 26, 2009 at 6:00 PM, Tim Parkin <in...@timparkin.co.uk> wrote:
> Antony Blakey wrote:
>>
>> On 26/03/2009, at 6:18 AM, Tim Parkin wrote:
>>
>>> I don't want to have to repeat myself but *it's not about the
>>> consistency or atomicity*. It's about being able to make two or more
>>> changes in a single request (via a UI or API) and if the last one fails,
>>> being able to roll the first ones back and tell the user "Sorry,
>>> something went wrong, would you like to try again" instead of "you have
>>> a partial success, how would you like to deal with it?"
>>
>> In what way is that not atomicity?
>
> Well the difference is I'm more interested the ability to rollback than
> the atomicity. The philosophical objection (AFAICT) is to the atomicity
> of bulk_docs. So if we can simplify the rollback that would be goal
> number 1 acheived..
There is a ticket to allow a database to be rolled back to a specific
sequence id. Of course it can not be rolled to a seq-id that is older
than the last compaction.
https://issues.apache.org/jira/browse/COUCHDB-120
With this implemented, if a user has a node to themselves, they can
always roll back to an earlier state. Replication to a remote master
node would be the equivalent of committing the local transaction. Of
course other users of the remote master will see intermediate as the
replication proceeds, so it's not really a transaction, just the
ability to rollback some actions.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Antony Blakey wrote:
>
> On 26/03/2009, at 6:18 AM, Tim Parkin wrote:
>
>> I don't want to have to repeat myself but *it's not about the
>> consistency or atomicity*. It's about being able to make two or more
>> changes in a single request (via a UI or API) and if the last one fails,
>> being able to roll the first ones back and tell the user "Sorry,
>> something went wrong, would you like to try again" instead of "you have
>> a partial success, how would you like to deal with it?"
>
> In what way is that not atomicity?
Well the difference is I'm more interested the ability to rollback than
the atomicity. The philosophical objection (AFAICT) is to the atomicity
of bulk_docs. So if we can simplify the rollback that would be goal
number 1 acheived..
The simplest way to do this would probably be to reinstate bulk_docs I
imagine (as your comment below points out). The alternative is to create
a virtual revision layer system over couch, which we're testing and
writing up, but this would have interesting repurcussions (the system
would probably not use couchdb's replication model as each replication
is just a union and you would have to layer a new conflict system on top
of couch's - I'll try to write this up soon)
>
> I have a patch that adds/restores fail-on-conflict bulk update behaviour
> (ie. your rollback requirement, but with no intermediate state). It's
> 10-15 lines depending on formatting, i.e. fairly trivial, so it should
> be easy to keep it on HEAD. I trigger it explicitly by adding
> fail-on-conflict: true to the top level json in the bulk request, which
> means that existing tests pass because the default semantics are unpatched.
>
I'd be very interested - could I have a play with it?
Cheers
Tim
Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Posted by Antony Blakey <an...@gmail.com>.
On 26/03/2009, at 6:18 AM, Tim Parkin wrote:
> I don't want to have to repeat myself but *it's not about the
> consistency or atomicity*. It's about being able to make two or more
> changes in a single request (via a UI or API) and if the last one
> fails,
> being able to roll the first ones back and tell the user "Sorry,
> something went wrong, would you like to try again" instead of "you
> have
> a partial success, how would you like to deal with it?"
In what way is that not atomicity?
I have a patch that adds/restores fail-on-conflict bulk update
behaviour (ie. your rollback requirement, but with no intermediate
state). It's 10-15 lines depending on formatting, i.e. fairly trivial,
so it should be easy to keep it on HEAD. I trigger it explicitly by
adding fail-on-conflict: true to the top level json in the bulk
request, which means that existing tests pass because the default
semantics are unpatched.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
All that is required for evil to triumph is that good men do nothing.
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Damien Katz wrote:
>> The upshot appears to be that CouchDB is limited to only changing a
>> single document at a time through a user interface (unless you want to
>> add lots of work to handle conflicts).. Could I have a confirmation of
>> this so I can blog about it.
>
> That pretty much true, CouchDB offers no inter-document consistency
> guarantees.
>
I don't want to have to repeat myself but *it's not about the
consistency or atomicity*. It's about being able to make two or more
changes in a single request (via a UI or API) and if the last one fails,
being able to roll the first ones back and tell the user "Sorry,
something went wrong, would you like to try again" instead of "you have
a partial success, how would you like to deal with it?"
>> It's a pretty fundamental restriction and
>> one I'm sure people who want to use CouchDB would want to know about.
>
> You could help by updating the wiki documentation to make this clearer.
> Multiple places if necessary.
>
Very happily - are you confirming that we will never have a way of
applying a set of changes and have them all succeed or all fail?
e.g. if we could check for conflicts in a validation, that would solve
the problem.
If the discussion is over (and I hope it isn't) then I'll happily
publicise and document the issue, however saddened I am about the
conclusion.
Tim
Re: Restricting user interactions to a single document -- was [VOTE] Apache CouchDB 0.9.0 release
Posted by Damien Katz <da...@apache.org>.
On Mar 25, 2009, at 8:50 AM, Tim Parkin wrote:
> Chris Anderson wrote:
> -- aa --
>>
>> I think I understand the issue. I think there are two ways to
>> approach
>> a solution. One is to confine end-user updates to a single key. This
>> approach is the classic model for key/value stores.
>
> Pretty unfeasible I would think..
>
>> If your domain requires that edits are saved in multiple documents,
>> the complexity grows. If you can control replication, and ensure that
>> each user has a node to themselves, then you can treat edits between
>> replications as a transaction, and the application can roll back any
>> thing that has happened since the last outbound replication. It would
>> require a library between the UI and storage if you want to make that
>> simple for the user.
>>
>
> Fairly unfeasible for a database with 1m+ users.. and I imagine it
> won't
> be particularly fast to re-replicate the whole db on failure.
>
>> If you are working in an environment where the application can't
>> treat
>> replication as a (soft) transaction boundary (hot-swap, or multiple
>> concurrent users) then you'll need to break updates out into
>> individual documents. A user can start an interactive transaction,
>> and
>> mark all updates with the transaction id. Then you can use a view to
>> show only updates that are associated with a closed transaction.
>>
>> In this explicit-transaction use case, non-committed updates may be
>> replicated, and it is the responsibility of the application to read
>> data through a view which only shows updates that belong to finished
>> transactions.
>>
>
> Which isn't particularly straightforward either and you lose lots of
> couchdb features (like conflict management) plus, as you say, you need
> to monitor replication etc..
>
>> The upshot is that bulk_docs can't and shouldn't give you any powers
>> that you don't have available with the individual document APIs, but
>> that doesn't mean your application can't provide those sorts of
>> interfaces.
>
> The upshot appears to be that CouchDB is limited to only changing a
> single document at a time through a user interface (unless you want to
> add lots of work to handle conflicts).. Could I have a confirmation of
> this so I can blog about it.
That pretty much true, CouchDB offers no inter-document consistency
guarantees.
> It's a pretty fundamental restriction and
> one I'm sure people who want to use CouchDB would want to know about.
You could help by updating the wiki documentation to make this
clearer. Multiple places if necessary.
-Damien
Re: Restricting user interactions to a single document -- was [VOTE]
Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Chris Anderson wrote:
-- aa --
>
> I think I understand the issue. I think there are two ways to approach
> a solution. One is to confine end-user updates to a single key. This
> approach is the classic model for key/value stores.
Pretty unfeasible I would think..
> If your domain requires that edits are saved in multiple documents,
> the complexity grows. If you can control replication, and ensure that
> each user has a node to themselves, then you can treat edits between
> replications as a transaction, and the application can roll back any
> thing that has happened since the last outbound replication. It would
> require a library between the UI and storage if you want to make that
> simple for the user.
>
Fairly unfeasible for a database with 1m+ users.. and I imagine it won't
be particularly fast to re-replicate the whole db on failure.
> If you are working in an environment where the application can't treat
> replication as a (soft) transaction boundary (hot-swap, or multiple
> concurrent users) then you'll need to break updates out into
> individual documents. A user can start an interactive transaction, and
> mark all updates with the transaction id. Then you can use a view to
> show only updates that are associated with a closed transaction.
>
> In this explicit-transaction use case, non-committed updates may be
> replicated, and it is the responsibility of the application to read
> data through a view which only shows updates that belong to finished
> transactions.
>
Which isn't particularly straightforward either and you lose lots of
couchdb features (like conflict management) plus, as you say, you need
to monitor replication etc..
> The upshot is that bulk_docs can't and shouldn't give you any powers
> that you don't have available with the individual document APIs, but
> that doesn't mean your application can't provide those sorts of
> interfaces.
The upshot appears to be that CouchDB is limited to only changing a
single document at a time through a user interface (unless you want to
add lots of work to handle conflicts).. Could I have a confirmation of
this so I can blog about it. It's a pretty fundamental restriction and
one I'm sure people who want to use CouchDB would want to know about.
Tim
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Noah Slater <ns...@apache.org>.
On Wed, Mar 25, 2009 at 12:44:07PM +0100, Chris Anderson wrote:
> I think I understand the issue. I think there are two ways to approach
> a solution. One is to confine end-user updates to a single key. This
> approach is the classic model for key/value stores.
Can we move this off to a different thread now, and keep this for voting.
Thanks,
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Mar 25, 2009 at 12:18 PM, Tim Parkin <in...@timparkin.co.uk> wrote:
> Chris Anderson wrote:
>>> I'd be interested in knowing what happened to the community discussion
>>> around the removal of the bulk_docs 'feature'? I've tried to raise this a
>>> couple of times but had little reaction. Am I right in understanding this
>>> lack of reaction as meaning there is going to be no discussion?
>>
>>
>> We've been concentrating on bulk docs documentation. In my experience,
>> most people who understand that the unit of consistency is the
>> document start to see ways of solving problems that work in a
>> key/value world. Some use-cases don't fit, but for the 80% case we're
>> better off with the simpler consistency model.
>>
>
> I think the real issue is one of misunderstanding.. I personally just
> want a way to rollback changes in order to deal with user interface
> issues. The document I posted discusses the issue and highlights the
> fact that the problem is not about consistency, it's about providing a
> way to rollback changes if part of them fails so that a user can apply a
> change by clicking submit and get a success/fail response.
>
I think I understand the issue. I think there are two ways to approach
a solution. One is to confine end-user updates to a single key. This
approach is the classic model for key/value stores.
If your domain requires that edits are saved in multiple documents,
the complexity grows. If you can control replication, and ensure that
each user has a node to themselves, then you can treat edits between
replications as a transaction, and the application can roll back any
thing that has happened since the last outbound replication. It would
require a library between the UI and storage if you want to make that
simple for the user.
If you are working in an environment where the application can't treat
replication as a (soft) transaction boundary (hot-swap, or multiple
concurrent users) then you'll need to break updates out into
individual documents. A user can start an interactive transaction, and
mark all updates with the transaction id. Then you can use a view to
show only updates that are associated with a closed transaction.
In this explicit-transaction use case, non-committed updates may be
replicated, and it is the responsibility of the application to read
data through a view which only shows updates that belong to finished
transactions.
The upshot is that bulk_docs can't and shouldn't give you any powers
that you don't have available with the individual document APIs, but
that doesn't mean your application can't provide those sorts of
interfaces.
> ... snip ...
>>
>> I think the general understanding is that CouchDB is built with a
>> certain minimalist simplicity in mind. We appreciate that some of our
>> users have demands that exceed our out-of-the-box functionality. I
>> think once we have a solid understanding of how to use CouchDB in a
>> distributed manner, we'll be on steady footing for more ambitious
>> consistency guarantees.
>>
>
> Just to reiterate.. it's not about consistency, it's about showing users
> a logical success/fail rather than saying to them.. "well a part of your
> change worked, part of it didn't - what would you like to do now?".
>
> The document I posted (I'll write a blog post about it if it helps)
> details the issue.
>
> Tim
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Chris Anderson wrote:
>> I'd be interested in knowing what happened to the community discussion
>> around the removal of the bulk_docs 'feature'? I've tried to raise this a
>> couple of times but had little reaction. Am I right in understanding this
>> lack of reaction as meaning there is going to be no discussion?
>
>
> We've been concentrating on bulk docs documentation. In my experience,
> most people who understand that the unit of consistency is the
> document start to see ways of solving problems that work in a
> key/value world. Some use-cases don't fit, but for the 80% case we're
> better off with the simpler consistency model.
>
I think the real issue is one of misunderstanding.. I personally just
want a way to rollback changes in order to deal with user interface
issues. The document I posted discusses the issue and highlights the
fact that the problem is not about consistency, it's about providing a
way to rollback changes if part of them fails so that a user can apply a
change by clicking submit and get a success/fail response.
... snip ...
>
> I think the general understanding is that CouchDB is built with a
> certain minimalist simplicity in mind. We appreciate that some of our
> users have demands that exceed our out-of-the-box functionality. I
> think once we have a solid understanding of how to use CouchDB in a
> distributed manner, we'll be on steady footing for more ambitious
> consistency guarantees.
>
Just to reiterate.. it's not about consistency, it's about showing users
a logical success/fail rather than saying to them.. "well a part of your
change worked, part of it didn't - what would you like to do now?".
The document I posted (I'll write a blog post about it if it helps)
details the issue.
Tim
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Mar 25, 2009 at 12:14 AM, Tim Parkin <in...@timparkin.co.uk> wrote:
> Noah Slater wrote:
>>
>> Hello,
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote for
>> release.
>>
>> We encourage the whole community to download and test these release
>> artifacts so
>> that any critical issues can be resolved before the release is made.
>> Everyone is
>> free to vote on this release, so get stuck in!
>
> I'd be interested in knowing what happened to the community discussion
> around the removal of the bulk_docs 'feature'? I've tried to raise this a
> couple of times but had little reaction. Am I right in understanding this
> lack of reaction as meaning there is going to be no discussion?
We've been concentrating on bulk docs documentation. In my experience,
most people who understand that the unit of consistency is the
document start to see ways of solving problems that work in a
key/value world. Some use-cases don't fit, but for the 80% case we're
better off with the simpler consistency model.
I'm working hard to make it easy for transactional conflict detection
to develop outside the core project. If it is in demand by many users,
comparison with the default consistency model will be worthwhile.
Damien has said he could see adding the feature back if people want it
and there's a good implementation.
I've moved the Bulk Docs API information to its own page:
http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>
> As some fairly serious issues have been raised about user interaction models
> I would hope that these would get addressed before commiting to a point
> release?
>
I think the general understanding is that CouchDB is built with a
certain minimalist simplicity in mind. We appreciate that some of our
users have demands that exceed our out-of-the-box functionality. I
think once we have a solid understanding of how to use CouchDB in a
distributed manner, we'll be on steady footing for more ambitious
consistency guarantees.
Chris
--
Chris Anderson jchrisa.net couch.io
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Antony Blakey <an...@gmail.com>.
On 25/03/2009, at 10:44 AM, Tim Parkin wrote:
> I'd be interested in knowing what happened to the community
> discussion around the removal of the bulk_docs 'feature'? I've tried
> to raise this a couple of times but had little reaction. Am I right
> in understanding this lack of reaction as meaning there is going to
> be no discussion?
I need the existing bulk_docs semantics, but I also need to stay on
trunk to get the replication enhancements.
Bulk_docs existing behaviour can be retained without forking and
without patching, as follows:
1. Copy the previous code into new files (in a new project) and edit
it - this is the real work;
2. Deploy CouchDB trunk;
3. Deploy this new project;
4. Setup your CouchDB configuration file to either repoint the
bulk_docs endpoint to your new code, or adds your new code at a new
endpoint;
4. When you start CouchDB, do this: ERL_AFLAGS='-pa <path to your new
project beam files>' couchdb ...
CouchDB's configuration mechanism allows you to completely change what
endpoints do what, and you can add arbitrary Erlang 'plugins'.
Note that this is still called CouchDB, so anyone with any concern
about that can rest easy.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Always have a vision. Why spend your life making other people’s dreams?
-- Orson Welles (1915-1985)
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Tim Parkin <in...@timparkin.co.uk>.
Noah Slater wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
I'd be interested in knowing what happened to the community discussion
around the removal of the bulk_docs 'feature'? I've tried to raise this
a couple of times but had little reaction. Am I right in understanding
this lack of reaction as meaning there is going to be no discussion?
As some fairly serious issues have been raised about user interaction
models I would hope that these would get addressed before commiting to a
point release?
Tim Parkin
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Sven Helmberger <sv...@gmx.de>.
Noah Slater schrieb:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
+1 works fine on Ubuntu 8.10, Erlang R13A. jcouchdb tests all green.
Regards,
Sven Helmberger
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Jan Lehnardt <ja...@apache.org>.
On 24 Mar 2009, at 15:16, Matt Goodall wrote:
> 2009/3/24 Noah Slater <ns...@apache.org>:
>> Hello,
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote
>> for release.
>
> Sorry but a blocker was reopened earlier,
> https://issues.apache.org/jira/browse/COUCHDB-4.
This is not blocking for 0.9
Cheers
Jan
--
>
>>
>> We encourage the whole community to download and test these release
>> artifacts so
>> that any critical issues can be resolved before the release is
>> made. Everyone is
>> free to vote on this release, so get stuck in!
>>
>> We are voting on the following release artifacts:
>>
>> http://people.apache.org/~nslater/dist/0.9.0/
>>
>> These artifacts have been built from the 0.9.0 tag in Subversion:
>>
>> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>>
>> Happy voting,
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>>
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Matt Goodall <ma...@gmail.com>.
2009/3/24 Noah Slater <ns...@apache.org>:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
Sorry but a blocker was reopened earlier,
https://issues.apache.org/jira/browse/COUCHDB-4.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Zachary Zolton <za...@gmail.com>.
Just setup a new EC2 instance with Ubuntu 8.04, and ran my app's unit
tests against it.
All tests passed. +1
On Tue, Mar 24, 2009 at 11:39 AM, Damien Katz <da...@apache.org> wrote:
> FYI, I'm abstaining from this vote as I have been on paternity leave and am
> not closely following the issues or looking at the artifacts.
>
> However, I have no issues or objections either and am rather hopeful we can
> have a release soon. I will of course support whatever decisions the rest of
> the community arrives at.
>
> -Damien
>
>
> On Mar 24, 2009, at 10:00 AM, Noah Slater wrote:
>
>> Hello,
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote for
>> release.
>>
>> We encourage the whole community to download and test these release
>> artifacts so
>> that any critical issues can be resolved before the release is made.
>> Everyone is
>> free to vote on this release, so get stuck in!
>>
>> We are voting on the following release artifacts:
>>
>> http://people.apache.org/~nslater/dist/0.9.0/
>>
>> These artifacts have been built from the 0.9.0 tag in Subversion:
>>
>> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>>
>> Happy voting,
>>
>> --
>> Noah Slater, http://tumbolia.org/nslater
>
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Damien Katz <da...@apache.org>.
FYI, I'm abstaining from this vote as I have been on paternity leave
and am not closely following the issues or looking at the artifacts.
However, I have no issues or objections either and am rather hopeful
we can have a release soon. I will of course support whatever
decisions the rest of the community arrives at.
-Damien
On Mar 24, 2009, at 10:00 AM, Noah Slater wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote
> for release.
>
> We encourage the whole community to download and test these release
> artifacts so
> that any critical issues can be resolved before the release is made.
> Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Ben Damman <be...@shotguncollective.com>.
I successfully installed from trunk this morning on OS X 10.4 -- nice work
guys. I just subscribed to dev this morning, so I don't think my vote counts
for much but...
I think you've got a viable release for 0.9.
Kudos,
Ben Damman
"Wannabe Erlang Developer"
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Mar 24, 2009 at 10:00 AM, Noah Slater <ns...@apache.org> wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> Happy voting,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
+1
So far tested on Ubuntu 8.10. Rebuilding my OS X machine to double
check that as well.
Re: [VOTE RESULTS] (was Re: [VOTE] Apache CouchDB 0.9.0 release)
Posted by Noah Slater <ns...@apache.org>.
On Sat, Mar 28, 2009 at 12:43:36PM +1030, Antony Blakey wrote:
> Current codebase doesn't build because of this: https://issues.apache.org/jira/browse/COUCHDB-309
>
> I suggest fixing this rather than releasing a 0.9 that doesn't build.
The bug you mention only affects source code checked out from a git mirror.
The release artifact is completely unaffected.
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE RESULTS] (was Re: [VOTE] Apache CouchDB 0.9.0 release)
Posted by Antony Blakey <an...@gmail.com>.
Current codebase doesn't build because of this: https://issues.apache.org/jira/browse/COUCHDB-309
I suggest fixing this rather than releasing a 0.9 that doesn't build.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
What can be done with fewer [assumptions] is done in vain with more
-- William of Ockham (ca. 1285-1349)
Re: [VOTE RESULTS] (was Re: [VOTE] Apache CouchDB 0.9.0 release)
Posted by Paul Davis <pa...@gmail.com>.
Too lazy to type out a response following the Magna Carta so "No
taxation without representation!" Also, awesome unicode-complete
reference to American history.
On Fri, Mar 27, 2009 at 11:27 PM, Noah Slater <ns...@apache.org> wrote:
> Brethren, and Fellow Developerſ!
>
> On Sat, Mar 28, 2009 at 02:04:41AM +0000, Noah Slater wrote:
>> +1 Paul Davis (binding)
>
> It has come to my attention, that a certain Gentleman, otherwiſe respected
> within the community, is, notwithſtanding my utmost reſpect and admiration, not
> deſerving of a binding vote. If any Perſon ſhould be ſo hardy as to Ignore this
> meſsage, they may expect my ſeverest Reſntment.
>
> I beg to remain, Sir, your most humble and obedient servant,
>
> --
> Noah Slater, http://tumbolia.org/nslater
>
Re: [VOTE RESULTS] (was Re: [VOTE] Apache CouchDB 0.9.0 release)
Posted by Noah Slater <ns...@apache.org>.
Brethren, and Fellow Developerſ!
On Sat, Mar 28, 2009 at 02:04:41AM +0000, Noah Slater wrote:
> +1 Paul Davis (binding)
It has come to my attention, that a certain Gentleman, otherwiſe respected
within the community, is, notwithſtanding my utmost reſpect and admiration, not
deſerving of a binding vote. If any Perſon ſhould be ſo hardy as to Ignore this
meſsage, they may expect my ſeverest Reſntment.
I beg to remain, Sir, your most humble and obedient servant,
--
Noah Slater, http://tumbolia.org/nslater
[VOTE RESULTS] (was Re: [VOTE] Apache CouchDB 0.9.0 release)
Posted by Noah Slater <ns...@apache.org>.
Hello,
This is the largest vote turnout we've had so far. Thanks everyone!
The final tally of the vote is:
15 +1 votes
This exceeds the required minimum three +1 votes and the proposal passes.
The individual votes are as follows:
+1 Jan Lehnardt (binding)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<B7...@apache.org>
+1 Noah Slater (binding)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<20...@tumbolia.org>
+1 Paul Carey
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<13...@mail.gmail.com>
+1 Zachary Zolton
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<f7...@mail.gmail.com>
+1 Kore Nordmann
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<49...@kore-nordmann.de>
+1 Reed Underwood
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<b7...@mail.gmail.com>
+1 Jason Davies
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<DC...@jasondavies.com>
+1 Ben Browning
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<d7...@mail.gmail.com>
+1 Rob Evans
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<5c...@mail.gmail.com>
+1 Chris Anderson (binding)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<e2...@mail.gmail.com>
+1 Sven Helmberger
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<49...@gmx.de>
+1 Mark Gallop
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<49...@gmail.com>
+1 Paul Davis (binding)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<e2...@mail.gmail.com>
+1 Volker Mische
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<49...@gmail.com>
+1 Christopher Lenz (binding)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200903.mbox/<1D...@gmx.de>
Best,
--
Noah Slater, http://tumbolia.org/nslater
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Reed Underwood <re...@gmail.com>.
Twice loaded 2-3M docs, built views, and updated full-text indices
with couchdb-lucene (all on Ubuntu Hardy). All seems well with my
clients.
+1
-Reed
On Tue, Mar 24, 2009 at 1:57 PM, Kore Nordmann <ma...@kore-nordmann.de> wrote:
> Noah Slater wrote:
>> Hello,
>>
>> This is the first release after graduating the ASF Incubator.
>>
>> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>>
>> We encourage the whole community to download and test these release artifacts so
>> that any critical issues can be resolved before the release is made. Everyone is
>> free to vote on this release, so get stuck in!
>>
>> We are voting on the following release artifacts:
>>
>> http://people.apache.org/~nslater/dist/0.9.0/
>>
>> These artifacts have been built from the 0.9.0 tag in Subversion:
>>
>> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
>
> +1
>
> Ran PHPillow and Arbit test suites against latest trunk, and everything
> works just fine. :)
>
> Kind regards,
> Kore
>
> --
> Kore Nordmann (GPG 0xDDC70BBB)
> http://kore-nordmann.de/portfolio.html
>
>
Re: [VOTE] Apache CouchDB 0.9.0 release
Posted by Kore Nordmann <ma...@kore-nordmann.de>.
Noah Slater wrote:
> Hello,
>
> This is the first release after graduating the ASF Incubator.
>
> All 0.9.0 blockers have been resolved and I would like call a vote for release.
>
> We encourage the whole community to download and test these release artifacts so
> that any critical issues can be resolved before the release is made. Everyone is
> free to vote on this release, so get stuck in!
>
> We are voting on the following release artifacts:
>
> http://people.apache.org/~nslater/dist/0.9.0/
>
> These artifacts have been built from the 0.9.0 tag in Subversion:
>
> http://svn.apache.org/repos/asf/couchdb/tags/0.9.0/
+1
Ran PHPillow and Arbit test suites against latest trunk, and everything
works just fine. :)
Kind regards,
Kore
--
Kore Nordmann (GPG 0xDDC70BBB)
http://kore-nordmann.de/portfolio.html