Hi,
Apache CouchDB committers J Chris Anderson and Jan Lehnardt
are in London this week and we're hosting a CouchDB meetup
in the central London area.
You can add yourself to http://friendpaste.com/3yXeR06wGEVFfTh6ybtWzg
if you're coming to help with capacity planning. If you have a good
suggest
Hi dev@,
Chris Anderson and I will be at http://jsconf2009.com/ in April.
JSConf is near Washington, DC and this is not "too far"* from
Asheville, NC where Damien lives. We thought it would be cool
to hang out in Asheville in the week before JSConf to do some
face-to-face CouchDB hacking and we'
[
https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682751#action_12682751
]
Elliot Murphy commented on COUCHDB-290:
---
Wow, thanks for all the feedback! From read
In retrospect, naming the thread ' atomic ' wasn't
the right thing to do...
Tim
Antony Blakey wrote:
>
-- snip --
>
> I think that keeping these two points explicit results in simpler and
> more transparent reasoning around issues *such as* atomicity - in
> particular, why it will never happen.
>
> As far as rollback is concerned, the problem is that concurrent
> accessors
On 17/03/2009, at 11:46 PM, Dean Landolt wrote:
Interesting read -- and good examples. But I would argue there are
more than
philosophical drawbacks. As I understand it, it would mean giving up
the
replication feature entirely. Forever...or at least as long as bulk-
docs are
relied upon. Th
Dean Landolt wrote:
-- snip --
>> The possible application I'm talking about doesn't need transactions,
>> they just need a simple way of rolling back a set of changes
>> (preferably atomically but not necessarily). I'm not looking to banish
>> conflicts, just minimise them where possible.
>>
>
>
On Tue, Mar 17, 2009 at 9:49 AM, Tim Parkin wrote:
> Dean Landolt wrote:
> --snip --
> > Interesting read -- and good examples. But I would argue there are more
> than
> > philosophical drawbacks. As I understand it, it would mean giving up the
> > replication feature entirely. Forever...or at le
Dean Landolt wrote:
--snip --
> Interesting read -- and good examples. But I would argue there are more than
> philosophical drawbacks. As I understand it, it would mean giving up the
> replication feature entirely. Forever...or at least as long as bulk-docs are
> relied upon. There's more to repli
On Tue, Mar 17, 2009 at 8:10 AM, Tim Parkin wrote:
> I've been thinking about the change in bulk docs behaviour and wanted to
> discuss online but it;s difficult to get my thoughts across
> conversationally so I've written a little 'article'. I'd love feedback
> on it and if we can get some concl
>>> Hence, I propose to remove the MOVE feature.
>>
>> I had the impression that at some point MOVE would also (atomically)
>> move the underlying .view files if applied to a design doc. Such a
>> feature would be very useful for upgrading clients.
>>
>> Am I wrong, or was there ever such a proposa
On Tue, Mar 17, 2009 at 01:15:01PM +0100, Jan Lehnardt wrote:
> MOVE is commonly understood to be an atomic sequence of copy & delete.
> In CouchDB (single or multi-node) MOVE is not atomic.
I forgot that MOVE is from RFC2518 (WebDAV) not RFC2616 (HTTP).
The MOVE operation on a non-collection r
On 17 Mar 2009, at 13:01, Noah Slater wrote:
On Tue, Mar 17, 2009 at 12:58:46PM +0100, Jan Lehnardt wrote:
the feature doesn't work as advertised and creates false expectations
about atomicity of operations.
As advertised? The only intrinsic advertisement is the word MOVE
itself.
MOVE is
I've been thinking about the change in bulk docs behaviour and wanted to
discuss online but it;s difficult to get my thoughts across
conversationally so I've written a little 'article'. I'd love feedback
on it and if we can get some conclusions will write up a final document
about the issues as a w
[
https://issues.apache.org/jira/browse/COUCHDB-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682649#action_12682649
]
Jan Lehnardt commented on COUCHDB-183:
--
I applied the patch to my local copy and usin
On Tue, Mar 17, 2009 at 12:58:46PM +0100, Jan Lehnardt wrote:
> the feature doesn't work as advertised and creates false expectations
> about atomicity of operations.
As advertised? The only intrinsic advertisement is the word MOVE itself.
If there is a problem with expectation, this can be solve
On 17 Mar 2009, at 12:40, Paul Carey wrote:
Hence, I propose to remove the MOVE feature.
I had the impression that at some point MOVE would also (atomically)
move the underlying .view files if applied to a design doc. Such a
feature would be very useful for upgrading clients.
Am I wrong, or
On 17 Mar 2009, at 12:37, Noah Slater wrote:
On Tue, Mar 17, 2009 at 12:20:42PM +0100, Jan Lehnardt wrote:
Hi dev@,
CouchDB supports the HTTP method MOVE to move a
document to a new document id within a database. MOVE
is really just a convenience method for COPY & DELETE.
In fact internally,
> Hence, I propose to remove the MOVE feature.
I had the impression that at some point MOVE would also (atomically)
move the underlying .view files if applied to a design doc. Such a
feature would be very useful for upgrading clients.
Am I wrong, or was there ever such a proposal?
[
https://issues.apache.org/jira/browse/COUCHDB-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt updated COUCHDB-67:
Fix Version/s: (was: 0.9)
0.10
Move blocking form 0.9 to 0.10.
> Allow unic
On Tue, Mar 17, 2009 at 12:20:42PM +0100, Jan Lehnardt wrote:
> Hi dev@,
>
> CouchDB supports the HTTP method MOVE to move a
> document to a new document id within a database. MOVE
> is really just a convenience method for COPY & DELETE.
> In fact internally, it does just that. Damien says the COPY
[
https://issues.apache.org/jira/browse/COUCHDB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt updated COUCHDB-163:
-
Fix Version/s: (was: 0.9)
0.10
Move blocking from 0.9 to 0.10.
> replica
[
https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682638#action_12682638
]
Jan Lehnardt commented on COUCHDB-223:
--
Hi Dan, I think assignments can only go to co
On 16 Mar 2009, at 18:57, Damien Katz wrote:
Now fixed in trunk. Was there a bug report for this?
I can confirm that the errors no longer show up. Thanks!
Cheers
Jan
--
-Damien
On Mar 16, 2009, at 1:24 PM, Damien Katz wrote:
Good stack trace. Thanks Matt. I think I see the problem al
Hi dev@,
CouchDB supports the HTTP method MOVE to move a
document to a new document id within a database. MOVE
is really just a convenience method for COPY & DELETE.
In fact internally, it does just that. Damien says the COPY &
DELETE that MOVE does under the hood is not atomic on a
single node.
[
https://issues.apache.org/jira/browse/COUCHDB-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt closed COUCHDB-293.
Resolution: Fixed
Fixed in r755185. Thanks.
> uneneeded line in etc/couchdb/default_dev.ini
> ---
[
https://issues.apache.org/jira/browse/COUCHDB-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt closed COUCHDB-135.
Resolution: Fixed
> Offset regression between 0.8.0 and trunk
> --
On Mon, Mar 16, 2009 at 09:23:22PM -0700, David Van Couvering wrote:
> /bin/sh ../../libtool --mode=install /usr/bin/install -c '
> couch_erl_driver.la'
> '/usr/local/lib/couchdb/erlang/lib/couch-0.9.0a743231-incubating/priv/lib/
> couch_erl_driver.la'
> ../../libtool: line 778: X--mode=install
On Mon, Mar 16, 2009 at 09:45:23PM -0700, David Van Couvering wrote:
> Secondly, more info: it turns out that the default 'libtool' created in the
> root directory of couchdb was the problem. If I use /usr/local/bin/libtool
> instead, it works much better, and make install is successful.
The ./bo
uneneeded line in etc/couchdb/default_dev.ini
-
Key: COUCHDB-293
URL: https://issues.apache.org/jira/browse/COUCHDB-293
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affe
A deleted document may be resaved with an old revision and is then considered
undeleted
---
Key: COUCHDB-292
URL: https://issues.apache.org/jira/browse/COUCHDB-292
Pr
31 matches
Mail list logo
