Re: make couchdb more otpish
+1 for that, I don't like current directory structure.
Cheers,
Fedor.
On Tue, Jun 21, 2011 at 1:25 PM, Benoit Chesneau wrote:
> Hi all,
>
> I'm back on this topic. I know that @davisp made a script to split the
> file structure etc, but I wonder why or what we are waiting to do
> this. Also why using a script when we could move everything once? (and
> it should be done once imo)
>
> For the record i'm working with a month or two on rcouch and its last
> version in rcouch_templates [1] wich have splitted couch in some
> modules (couchjs, snappy, ejson) and in the same time allowed couch to
> be more otpish somehow. Maybe some tried it? Anyway I currently asking
> myself how we want to integrate things with couch and autotools for
> now. WHat is the file structure we want. Actually everything is in src
> even external libs.
>
> I propose to do smth like
>
> src/couch sources
> include/
> priv/
> libs/{mochiweb, snappy, oauth, ejson, ibrowse, ..} (or deps/)
> c_src/{couchjs, icu, spawnkillable?}
> etc/
> tests/
> bin/couch
> other files (with autoconfstuff)
>
> Related topic, I would like to introduce a rel/ folder that would
> allows us to build a real erlang release that would allows us to
> install couchdb system wide or create any dev release, wich again
> would be more otpish. We could also add the possibility to handle
> custom templates for that which would make maintainer and distributors
> happy. Most of these changes are already or rcouch so I would be glad
> to port them to this build system.
>
> What do you think about it ?
>
> - benoît
>
make couchdb more otpish
Hi all,
I'm back on this topic. I know that @davisp made a script to split the
file structure etc, but I wonder why or what we are waiting to do
this. Also why using a script when we could move everything once? (and
it should be done once imo)
For the record i'm working with a month or two on rcouch and its last
version in rcouch_templates [1] wich have splitted couch in some
modules (couchjs, snappy, ejson) and in the same time allowed couch to
be more otpish somehow. Maybe some tried it? Anyway I currently asking
myself how we want to integrate things with couch and autotools for
now. WHat is the file structure we want. Actually everything is in src
even external libs.
I propose to do smth like
src/couch sources
include/
priv/
libs/{mochiweb, snappy, oauth, ejson, ibrowse, ..} (or deps/)
c_src/{couchjs, icu, spawnkillable?}
etc/
tests/
bin/couch
other files (with autoconfstuff)
Related topic, I would like to introduce a rel/ folder that would
allows us to build a real erlang release that would allows us to
install couchdb system wide or create any dev release, wich again
would be more otpish. We could also add the possibility to handle
custom templates for that which would make maintainer and distributors
happy. Most of these changes are already or rcouch so I would be glad
to port them to this build system.
What do you think about it ?
- benoît
[jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
[ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052349#comment-13052349 ] Jason Smith commented on COUCHDB-1175: -- Great discussion. I also hope this fix goes into 1.2. Marcello, don't give up! You are speaking truth to power! Benoit, I agree the best thing is to identify the correct response to the variety of queries. If you see me on IRC, I volunteer to help you build the list. I suspect that once we clearly define the requirements, lo and behold, the solution will be to follow the standard. Filipe, your pull request will help, but it is slightly incorrect? The primary sort is the 'q' value but the secondary sort is the more specific type. foo/bar > foo/* > */* For CouchDB, I would not think that will cause a bug because the only mistake it could make is for "Accept: */*, text/html" which seems like a rare header value in the wild. OTOH, if IE8 really sends "bull/shit, more/shit, */*" then CouchDB should probably treat that as text/html. (AJAX tools like jQuery modify the header, so Couch is pretty sure this is a direct query for a resource intended to be displayed.) > Improve content type negotiation for couchdb JSON responses > --- > > Key: COUCHDB-1175 > URL: https://issues.apache.org/jira/browse/COUCHDB-1175 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.0.2 >Reporter: Robert Newson >Assignee: Robert Newson >Priority: Blocker > Fix For: 1.1.1, 1.2 > > > Currently we ignore qvalues when negotiation between 'application/json' and > 'text/plain' when returning JSON responses. > Specifically, we test directly for 'application/json' or 'text/plain' in the > Accept header. Different branches have different bugs, though. Trunk returns > 'application/json' if 'application/json' is present at all, even if it's less > preferred than 'text/plain' when qvalues are accounted for. > We should follow the standard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1193) Inconsistent decoding of rewritten query parameters
[
https://issues.apache.org/jira/browse/COUCHDB-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052266#comment-13052266
]
Marcos Zanona commented on COUCHDB-1193:
I am trying with the following:
{
"from" : "_view/model",
"to": "_view/type",
"query" : {
"startkey" : ["test"],
"endkey" : ["test_"],
"group_level" : "1"
}
}
it seems the group_level really doesn't change at all, actually it is acting
really weird, it changes the first time, when you move back to the old value it
doesn't change at all...really annoying :(
> Inconsistent decoding of rewritten query parameters
> ---
>
> Key: COUCHDB-1193
> URL: https://issues.apache.org/jira/browse/COUCHDB-1193
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.1
>Reporter: Johannes J. Schmidt
> Labels: rewriter
>
> {
> "from": "/",
> "to": "_view/q",
> "method": "GET",
> "query": {
> "limit": 30
> }
> }
> (exact rule: http://pastebin.com/tjyR5e9R)
> throws {"error":"unknown_error","reason":"badarg"}
> (complete trace: http://pastebin.com/rKQgbmeq)
> As daleharvey pointed out on irc, this is due to inconsitent JSON decoding of
> query params. daleharvey suggests a fix like in
> http://pastebin.me/0ed2942f6953cb00cab1bd53861c1568
> A temporarily fix is to quote the parameters:
> {
> "from": "/",
> "to": "_view/q",
> "method": "GET",
> "query": {
> "limit": "30"
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052238#comment-13052238 ] Randall Leeds commented on COUCHDB-1197: Anything else necessary to make trunk compile on windows? Is it standard on Windows to specify -llibX rather than just -lX? Or is curl just distributed strangely (e.g. Wldap32.lib vs libcurl.lib)? > trunk no longer builds on Windows > - > > Key: COUCHDB-1197 > URL: https://issues.apache.org/jira/browse/COUCHDB-1197 > Project: CouchDB > Issue Type: Bug > Components: Build System, JavaScript View Server > Environment: Windows 7 Enterprise x64 > Cygwin > MS Visual Studio 2008 Express >Reporter: Dave Cottlehuber > Labels: cygwin, windows > Fix For: 1.2 > > Attachments: COUCHDB-1197_fix_ejson.patch, > COUCHDB-1197_fix_libcurl.patch > > > ./configure fails > - can no longer correctly find libcurl (after COUCHDB-1042) and instead > compiles against cygwin's curl which is *bad*. Patch attached to resolve this. > - finds jsapi.h correctly but can no longer use it. Work by dch to identify > when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1199) Doc in _replicator db missing when using filter property
[
https://issues.apache.org/jira/browse/COUCHDB-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-1199:
---
Attachment: couchdb-1199-11x.patch
Andrew, the attached patch fixes the issue (for branch 1.1.x).
Will commit it soon.
> Doc in _replicator db missing when using filter property
>
>
> Key: COUCHDB-1199
> URL: https://issues.apache.org/jira/browse/COUCHDB-1199
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1
> Environment: Ubuntu 10.10
>Reporter: andrew henderson
>Assignee: Filipe Manana
> Attachments: couchdb-1199-11x.patch
>
>
> Scenario1 below works as expected, Scenario2 fails.
> Scenario1
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\}{"ok":true,"id":"test1_to_test2","rev":"1-df297eda4880633bc0442590724014ff"}
> Doc is created in _replicator
> Replication completes successfully
> Scenario2
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\,\"filter\":\"http:\/\/127.0.0.1:5984\/my_culture\/profile\/app_ddocs\"}
> {"ok":true,"id":"test1_to_test2","rev":"1-97641b372d500d842688d217f97081da"}
> Doc is not created in _replicator (in spite of 'ok' response above)
> No replication occurs.
> Now, I am not sure whether I got the right syntax in the filter property
> since I could find no documentation for it. In particular, whether the filter
> should be in the source db or _replicator. And do we use a full URL as above
> or just ddoc/filter name? The filter documented in Scenario2 does exist in
> source db.
> In any case, the doc in _replicator ought not to be getting lost as does
> happen.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1200) _update handler breaks after a conflict is resolved
[
https://issues.apache.org/jira/browse/COUCHDB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052225#comment-13052225
]
Paul Joseph Davis commented on COUCHDB-1200:
URL:
https://github.com/apache/couchdb/commit/3a52f24172e62361e18f01691f034daf6851dbab
> _update handler breaks after a conflict is resolved
> ---
>
> Key: COUCHDB-1200
> URL: https://issues.apache.org/jira/browse/COUCHDB-1200
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Replication
>Affects Versions: 1.1
>Reporter: Pete Vander Giessen
> Fix For: 1.1.1
>
> Attachments: test_conflict_mine.sh
>
>
> My update handlers break after I've introduced and resolved a conflict.
> Despite the conflict being resolve, I get the following error when trying to
> run an update handler on a once-conflicted document:
> {"error":"conflict","reason":"Document update conflict."}
> The attached script reproduces the issue on 1.1.x. The issue does not appear
> when run against a build of trunk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1200) _update handler breaks after a conflict is resolved
[
https://issues.apache.org/jira/browse/COUCHDB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052220#comment-13052220
]
Robert Newson commented on COUCHDB-1200:
Looks like it was fixed by this commit: 3a52f24172e62361e18f01691f034daf6851dbab
> _update handler breaks after a conflict is resolved
> ---
>
> Key: COUCHDB-1200
> URL: https://issues.apache.org/jira/browse/COUCHDB-1200
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Replication
>Affects Versions: 1.1
>Reporter: Pete Vander Giessen
> Fix For: 1.1.1
>
> Attachments: test_conflict_mine.sh
>
>
> My update handlers break after I've introduced and resolved a conflict.
> Despite the conflict being resolve, I get the following error when trying to
> run an update handler on a once-conflicted document:
> {"error":"conflict","reason":"Document update conflict."}
> The attached script reproduces the issue on 1.1.x. The issue does not appear
> when run against a build of trunk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1200) _update handler breaks after a conflict is resolved
[
https://issues.apache.org/jira/browse/COUCHDB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1200:
---
Fix Version/s: 1.1.1
If it doesn't occur on trunk let's find what fixed this and get it on 1.1.1.
> _update handler breaks after a conflict is resolved
> ---
>
> Key: COUCHDB-1200
> URL: https://issues.apache.org/jira/browse/COUCHDB-1200
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Replication
>Affects Versions: 1.1
>Reporter: Pete Vander Giessen
> Fix For: 1.1.1
>
> Attachments: test_conflict_mine.sh
>
>
> My update handlers break after I've introduced and resolved a conflict.
> Despite the conflict being resolve, I get the following error when trying to
> run an update handler on a once-conflicted document:
> {"error":"conflict","reason":"Document update conflict."}
> The attached script reproduces the issue on 1.1.x. The issue does not appear
> when run against a build of trunk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-648) _update handler ignores "code" in response doc
[
https://issues.apache.org/jira/browse/COUCHDB-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052146#comment-13052146
]
Michael Coyne commented on COUCHDB-648:
---
Being able to set response codes for "failed" updates would be very useful. I
feel it's more inline with the API overall as well.
+1 for this feature.
> _update handler ignores "code" in response doc
> --
>
> Key: COUCHDB-648
> URL: https://issues.apache.org/jira/browse/COUCHDB-648
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Environment: CouchDB from HEAD
>Reporter: Cliff Stanford
> Labels: update
> Attachments:
> 0001-Document-update-handlers-now-honor-code-in-response-.patch
>
>
> When using an _update handler, it should be possible to return a response
> code.
> return [ doc, {
> headers : { "Location" : "/" },
> code : 303,
> body : 'Redirecting'
> }];
> Should return 303 (the redirect for POST) but in fact, on a successful create
> returns 201. This means it is not possible to use the browser to POST as you
> cannot redirect on return. This feels like a bug.
> In any case, I would respectfully suggest that the syntax of the _update
> handler be changed so that there is a store(doc) call (or similar) which
> returns a JSON object to the update handler so that the handler may redirect
> appropriately. That would make it possible to do updates client-side with
> little or no client-side javascript.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1200) _update handler breaks after a conflict is resolved
[
https://issues.apache.org/jira/browse/COUCHDB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Vander Giessen updated COUCHDB-1200:
-
Attachment: test_conflict_mine.sh
Script to reproduce the problem.
> _update handler breaks after a conflict is resolved
> ---
>
> Key: COUCHDB-1200
> URL: https://issues.apache.org/jira/browse/COUCHDB-1200
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Replication
>Affects Versions: 1.1
>Reporter: Pete Vander Giessen
> Attachments: test_conflict_mine.sh
>
>
> My update handlers break after I've introduced and resolved a conflict.
> Despite the conflict being resolve, I get the following error when trying to
> run an update handler on a once-conflicted document:
> {"error":"conflict","reason":"Document update conflict."}
> The following script reproduces the issue on 1.1.x. The issue does not appear
> when run against a build of trunk:
> #!/bin/bash
> export HOST=http://localhost:5984
> echo "Step 1a -- setup dbs"
> curl -X DELETE $HOST/db0
> curl -X DELETE $HOST/db1
> curl -X PUT $HOST/db0
> curl -X PUT $HOST/db1
> echo "step 1b -- create an update handler "
> curl -X PUT $HOST/db0/_design/foo -d '{"updates":{"bar":"function(doc, req) {
> doc.foo=1; return [doc, \"ok\"];}"}}'
> echo "step 2 -- create a doc"
> curl -X PUT $HOST/db0/doc1 -d '{content}'
> curl -X GET $HOST/db0/doc1
> echo "step 3 -- replicate"
> curl -X POST $HOST/_replicate -d '{"source":"db0","target":"db1"}' -H
> "Content-Type:application/json"
> echo "step 4 -- a new version of the doc on both dbs"
> curl -X PUT $HOST/db0/doc1 -d
> '{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some content"}'
> curl -X PUT $HOST/db1/doc1 -d
> '{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some different
> content"}'
> echo "step 5 -- create a conflict "
> curl -X POST $HOST/_replicate -d '{"target":"db0","source":"db1"}' -H
> "Content-Type:application/json"
> echo "confirm conflict"
> curl -X GET $HOST/db0/doc1?conflicts=true
> echo "step 6 -- resolve the conflict"
> curl -X DELETE $HOST/db0/doc1?rev=2-2efe11aab7e71ce9124a1039129512da
> echo "step 7 -- check to make sure resolved"
> curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
> echo "step 8 -- attempt to PUT to our update handler: this produces the error"
> curl -X PUT
> $HOST/db0/_design/foo/_update/bar/doc1?2-3b2f178dbc5e76cbd8df3ddca1963f4b -d
> '{}'
> echo "step 9 -- double-check that conflict was resolved"
> curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
> echo "step 10 -- confirm that we can still do a normal PUT"
> curl -X PUT $HOST/db0/doc1 -d
> '{"_id":"doc1","_rev":"2-3b2f178dbc5e76cbd8df3ddca1963f4b","content":"some
> content fnord"}'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1200) _update handler breaks after a conflict is resolved
[
https://issues.apache.org/jira/browse/COUCHDB-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Vander Giessen updated COUCHDB-1200:
-
Description:
My update handlers break after I've introduced and resolved a conflict. Despite
the conflict being resolve, I get the following error when trying to run an
update handler on a once-conflicted document:
{"error":"conflict","reason":"Document update conflict."}
The attached script reproduces the issue on 1.1.x. The issue does not appear
when run against a build of trunk.
was:
My update handlers break after I've introduced and resolved a conflict. Despite
the conflict being resolve, I get the following error when trying to run an
update handler on a once-conflicted document:
{"error":"conflict","reason":"Document update conflict."}
The following script reproduces the issue on 1.1.x. The issue does not appear
when run against a build of trunk:
#!/bin/bash
export HOST=http://localhost:5984
echo "Step 1a -- setup dbs"
curl -X DELETE $HOST/db0
curl -X DELETE $HOST/db1
curl -X PUT $HOST/db0
curl -X PUT $HOST/db1
echo "step 1b -- create an update handler "
curl -X PUT $HOST/db0/_design/foo -d '{"updates":{"bar":"function(doc, req) {
doc.foo=1; return [doc, \"ok\"];}"}}'
echo "step 2 -- create a doc"
curl -X PUT $HOST/db0/doc1 -d '{content}'
curl -X GET $HOST/db0/doc1
echo "step 3 -- replicate"
curl -X POST $HOST/_replicate -d '{"source":"db0","target":"db1"}' -H
"Content-Type:application/json"
echo "step 4 -- a new version of the doc on both dbs"
curl -X PUT $HOST/db0/doc1 -d
'{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some content"}'
curl -X PUT $HOST/db1/doc1 -d
'{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some different
content"}'
echo "step 5 -- create a conflict "
curl -X POST $HOST/_replicate -d '{"target":"db0","source":"db1"}' -H
"Content-Type:application/json"
echo "confirm conflict"
curl -X GET $HOST/db0/doc1?conflicts=true
echo "step 6 -- resolve the conflict"
curl -X DELETE $HOST/db0/doc1?rev=2-2efe11aab7e71ce9124a1039129512da
echo "step 7 -- check to make sure resolved"
curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
echo "step 8 -- attempt to PUT to our update handler: this produces the error"
curl -X PUT
$HOST/db0/_design/foo/_update/bar/doc1?2-3b2f178dbc5e76cbd8df3ddca1963f4b -d
'{}'
echo "step 9 -- double-check that conflict was resolved"
curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
echo "step 10 -- confirm that we can still do a normal PUT"
curl -X PUT $HOST/db0/doc1 -d
'{"_id":"doc1","_rev":"2-3b2f178dbc5e76cbd8df3ddca1963f4b","content":"some
content fnord"}'
> _update handler breaks after a conflict is resolved
> ---
>
> Key: COUCHDB-1200
> URL: https://issues.apache.org/jira/browse/COUCHDB-1200
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, Replication
>Affects Versions: 1.1
>Reporter: Pete Vander Giessen
> Attachments: test_conflict_mine.sh
>
>
> My update handlers break after I've introduced and resolved a conflict.
> Despite the conflict being resolve, I get the following error when trying to
> run an update handler on a once-conflicted document:
> {"error":"conflict","reason":"Document update conflict."}
> The attached script reproduces the issue on 1.1.x. The issue does not appear
> when run against a build of trunk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1200) _update handler breaks after a conflict is resolved
_update handler breaks after a conflict is resolved
---
Key: COUCHDB-1200
URL: https://issues.apache.org/jira/browse/COUCHDB-1200
Project: CouchDB
Issue Type: Bug
Components: Database Core, Replication
Affects Versions: 1.1
Reporter: Pete Vander Giessen
My update handlers break after I've introduced and resolved a conflict. Despite
the conflict being resolve, I get the following error when trying to run an
update handler on a once-conflicted document:
{"error":"conflict","reason":"Document update conflict."}
The following script reproduces the issue on 1.1.x. The issue does not appear
when run against a build of trunk:
#!/bin/bash
export HOST=http://localhost:5984
echo "Step 1a -- setup dbs"
curl -X DELETE $HOST/db0
curl -X DELETE $HOST/db1
curl -X PUT $HOST/db0
curl -X PUT $HOST/db1
echo "step 1b -- create an update handler "
curl -X PUT $HOST/db0/_design/foo -d '{"updates":{"bar":"function(doc, req) {
doc.foo=1; return [doc, \"ok\"];}"}}'
echo "step 2 -- create a doc"
curl -X PUT $HOST/db0/doc1 -d '{content}'
curl -X GET $HOST/db0/doc1
echo "step 3 -- replicate"
curl -X POST $HOST/_replicate -d '{"source":"db0","target":"db1"}' -H
"Content-Type:application/json"
echo "step 4 -- a new version of the doc on both dbs"
curl -X PUT $HOST/db0/doc1 -d
'{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some content"}'
curl -X PUT $HOST/db1/doc1 -d
'{"_rev":"1-05a05c54cce81cc30df678afeab60f6c","content":"some different
content"}'
echo "step 5 -- create a conflict "
curl -X POST $HOST/_replicate -d '{"target":"db0","source":"db1"}' -H
"Content-Type:application/json"
echo "confirm conflict"
curl -X GET $HOST/db0/doc1?conflicts=true
echo "step 6 -- resolve the conflict"
curl -X DELETE $HOST/db0/doc1?rev=2-2efe11aab7e71ce9124a1039129512da
echo "step 7 -- check to make sure resolved"
curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
echo "step 8 -- attempt to PUT to our update handler: this produces the error"
curl -X PUT
$HOST/db0/_design/foo/_update/bar/doc1?2-3b2f178dbc5e76cbd8df3ddca1963f4b -d
'{}'
echo "step 9 -- double-check that conflict was resolved"
curl "$HOST/db0/doc1?conflicts=true&deleted_conflicts=true"
echo "step 10 -- confirm that we can still do a normal PUT"
curl -X PUT $HOST/db0/doc1 -d
'{"_id":"doc1","_rev":"2-3b2f178dbc5e76cbd8df3ddca1963f4b","content":"some
content fnord"}'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1199) Doc in _replicator db missing when using filter property
[
https://issues.apache.org/jira/browse/COUCHDB-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana reassigned COUCHDB-1199:
--
Assignee: Filipe Manana
> Doc in _replicator db missing when using filter property
>
>
> Key: COUCHDB-1199
> URL: https://issues.apache.org/jira/browse/COUCHDB-1199
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1
> Environment: Ubuntu 10.10
>Reporter: andrew henderson
>Assignee: Filipe Manana
>
> Scenario1 below works as expected, Scenario2 fails.
> Scenario1
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\}{"ok":true,"id":"test1_to_test2","rev":"1-df297eda4880633bc0442590724014ff"}
> Doc is created in _replicator
> Replication completes successfully
> Scenario2
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\,\"filter\":\"http:\/\/127.0.0.1:5984\/my_culture\/profile\/app_ddocs\"}
> {"ok":true,"id":"test1_to_test2","rev":"1-97641b372d500d842688d217f97081da"}
> Doc is not created in _replicator (in spite of 'ok' response above)
> No replication occurs.
> Now, I am not sure whether I got the right syntax in the filter property
> since I could find no documentation for it. In particular, whether the filter
> should be in the source db or _replicator. And do we use a full URL as above
> or just ddoc/filter name? The filter documented in Scenario2 does exist in
> source db.
> In any case, the doc in _replicator ought not to be getting lost as does
> happen.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1199) Doc in _replicator db missing when using filter property
[
https://issues.apache.org/jira/browse/COUCHDB-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051947#comment-13051947
]
Filipe Manana commented on COUCHDB-1199:
Thanks Andrew.
I was able to reproduce it. It happens only when there's a filter specified
which doesn't exist, throwing an exception and causing the replicator database
gen_server to be restarted 10 times by the supervisor, after which is no longer
restarted anymore.
I'll fix this asap.
> Doc in _replicator db missing when using filter property
>
>
> Key: COUCHDB-1199
> URL: https://issues.apache.org/jira/browse/COUCHDB-1199
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.1
> Environment: Ubuntu 10.10
>Reporter: andrew henderson
>
> Scenario1 below works as expected, Scenario2 fails.
> Scenario1
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\}{"ok":true,"id":"test1_to_test2","rev":"1-df297eda4880633bc0442590724014ff"}
> Doc is created in _replicator
> Replication completes successfully
> Scenario2
> curl -X POST 'http://127.0.0.1:5984/_replicator/' -H "Content-Type:
> application/json" -d
> {\"_id\":\"test1_to_test2\"\,\"source\":\"my_culture\"\,\"target\":\"http:\/\/127.0.0.1:5984\/test2\"\,\"create_target\":\true\,\"filter\":\"http:\/\/127.0.0.1:5984\/my_culture\/profile\/app_ddocs\"}
> {"ok":true,"id":"test1_to_test2","rev":"1-97641b372d500d842688d217f97081da"}
> Doc is not created in _replicator (in spite of 'ok' response above)
> No replication occurs.
> Now, I am not sure whether I got the right syntax in the filter property
> since I could find no documentation for it. In particular, whether the filter
> should be in the source db or _replicator. And do we use a full URL as above
> or just ddoc/filter name? The filter documented in Scenario2 does exist in
> source db.
> In any case, the doc in _replicator ought not to be getting lost as does
> happen.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
[ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051946#comment-13051946 ] Filipe Manana commented on COUCHDB-1175: This should help in choosing the content-type the request prefers when it accepts multiple (explicit, via type/* or */* and with or without q) https://github.com/mochi/mochiweb/pull/49 > Improve content type negotiation for couchdb JSON responses > --- > > Key: COUCHDB-1175 > URL: https://issues.apache.org/jira/browse/COUCHDB-1175 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.0.2 >Reporter: Robert Newson >Assignee: Robert Newson >Priority: Blocker > Fix For: 1.1.1, 1.2 > > > Currently we ignore qvalues when negotiation between 'application/json' and > 'text/plain' when returning JSON responses. > Specifically, we test directly for 'application/json' or 'text/plain' in the > Accept header. Different branches have different bugs, though. Trunk returns > 'application/json' if 'application/json' is present at all, even if it's less > preferred than 'text/plain' when qvalues are accounted for. > We should follow the standard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
[ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051944#comment-13051944 ] Marcello Nuccio commented on COUCHDB-1175: -- ok, I give up :-) However, the post you suggested gives also a simple solution: Frameworks can enhance performance by ignoring the Accept header and relying on '.xml'-like extensions. Is it applicable to CouchApps? > Improve content type negotiation for couchdb JSON responses > --- > > Key: COUCHDB-1175 > URL: https://issues.apache.org/jira/browse/COUCHDB-1175 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.0.2 >Reporter: Robert Newson >Assignee: Robert Newson >Priority: Blocker > Fix For: 1.1.1, 1.2 > > > Currently we ignore qvalues when negotiation between 'application/json' and > 'text/plain' when returning JSON responses. > Specifically, we test directly for 'application/json' or 'text/plain' in the > Accept header. Different branches have different bugs, though. Trunk returns > 'application/json' if 'application/json' is present at all, even if it's less > preferred than 'text/plain' when qvalues are accounted for. > We should follow the standard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1197) trunk no longer builds on Windows
[ https://issues.apache.org/jira/browse/COUCHDB-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cottlehuber updated COUCHDB-1197: -- Attachment: COUCHDB-1197_fix_ejson.patch fix ejson headers to compile on windows. > trunk no longer builds on Windows > - > > Key: COUCHDB-1197 > URL: https://issues.apache.org/jira/browse/COUCHDB-1197 > Project: CouchDB > Issue Type: Bug > Components: Build System, JavaScript View Server > Environment: Windows 7 Enterprise x64 > Cygwin > MS Visual Studio 2008 Express >Reporter: Dave Cottlehuber > Labels: cygwin, windows > Fix For: 1.2 > > Attachments: COUCHDB-1197_fix_ejson.patch, > COUCHDB-1197_fix_libcurl.patch > > > ./configure fails > - can no longer correctly find libcurl (after COUCHDB-1042) and instead > compiles against cygwin's curl which is *bad*. Patch attached to resolve this. > - finds jsapi.h correctly but can no longer use it. Work by dch to identify > when it broke and how to fix this underway. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
On Mon, Jun 20, 2011 at 12:19 PM, Robert Newson (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051903#comment-13051903 > ] > > Robert Newson commented on COUCHDB-1175: > > > I think IE8 still sends; > > Accept: image/jpeg, application/x-ms-application, image/gif, > application/xaml+xml, image/pjpeg, application/x-ms-xbap, > application/x-shockwave-flash, application/msword, */* > > http://www.gethifi.com/blog/browser-rest-http-accept-headers > > >> Improve content type negotiation for couchdb JSON responses >> --- >> >> Key: COUCHDB-1175 >> URL: https://issues.apache.org/jira/browse/COUCHDB-1175 >> Project: CouchDB >> Issue Type: Improvement >> Affects Versions: 1.0.2 >> Reporter: Robert Newson >> Assignee: Robert Newson >> Priority: Blocker >> Fix For: 1.1.1, 1.2 >> >> >> Currently we ignore qvalues when negotiation between 'application/json' and >> 'text/plain' when returning JSON responses. >> Specifically, we test directly for 'application/json' or 'text/plain' in the >> Accept header. Different branches have different bugs, though. Trunk returns >> 'application/json' if 'application/json' is present at all, even if it's >> less preferred than 'text/plain' when qvalues are accounted for. >> We should follow the standard. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > status update: I'm still on my API list blah. Hopefully I will finished it until tomorrow, in the mean time we can use as a start the api doc done by couchbase. - benoit
[jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses
[ https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051903#comment-13051903 ] Robert Newson commented on COUCHDB-1175: I think IE8 still sends; Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */* http://www.gethifi.com/blog/browser-rest-http-accept-headers > Improve content type negotiation for couchdb JSON responses > --- > > Key: COUCHDB-1175 > URL: https://issues.apache.org/jira/browse/COUCHDB-1175 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 1.0.2 >Reporter: Robert Newson >Assignee: Robert Newson >Priority: Blocker > Fix For: 1.1.1, 1.2 > > > Currently we ignore qvalues when negotiation between 'application/json' and > 'text/plain' when returning JSON responses. > Specifically, we test directly for 'application/json' or 'text/plain' in the > Accept header. Different branches have different bugs, though. Trunk returns > 'application/json' if 'application/json' is present at all, even if it's less > preferred than 'text/plain' when qvalues are accounted for. > We should follow the standard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
