On 23 Jan 2011, at 16:03, Robert Newson wrote:
> I can see utility in the original proposal, my only point is whether
> it would still be utile if other mechanisms were introduced. You've
> clarified that the two cases are distinct, so it seems reasonable to
> me now.
>
> However, I'd hope we'd
I can see utility in the original proposal, my only point is whether
it would still be utile if other mechanisms were introduced. You've
clarified that the two cases are distinct, so it seems reasonable to
me now.
However, I'd hope we'd return the doc and not just the _rev. The only
thing returnin
The confusion point here is that there are two different types of conflict.
1. _rev mismatch on regular write. — This is the quoted scenario. Returning the
expected _rev with the error result allows to remove an extra GET request. The
replicator never does this.
2. _rev mismatch on replication
These are also interesting ideas, but I don't think they adequately satisfy
this particular write-heavy scenario. The client receiving the 409 has in hand
the doc they wished to write and may just to add a
field or update one. A general resolve_conflict function is a good idea for
certain colla
Oooh, crosspost.
Had a similar chat on IRC last night.
I'm -0 on returning the doc during a 409 PUT just because I think
there are other options that might be preferred.
For example, allowing a read_repair function in ddocs, that would take
all conflicting revisions as input and return the resol
On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau wrote:
>
> Imo the thing we could have in view, except this plugin "support", is
> a simple api to call any part of couchdb we need. Something as simple
> as the HTTP api but for erlang.
>
> I'm thinking to have a couchbeam pure erlang api for exa
+1
this sounds like an excellent idea.
On Jan 23, 2011, at 12:21 AM, kowsik wrote:
> I've been spending a fair bit of time on profiling the performance
> aspects of Couch. One common recurring theme is updating documents on
> a write-heavy site. This is currently what happens:
>
> PUT /db/doc
[
https://issues.apache.org/jira/browse/COUCHDB-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt reopened COUCHDB-759:
--
Reopening because of last comment.
> rewriter should be securely jailed in a single database by d
[
https://issues.apache.org/jira/browse/COUCHDB-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985296#action_12985296
]
Martin Hilbig commented on COUCHDB-759:
---
hi,
i would like to see this bug reopend,
