[jira] [Resolved] (COUCHDB-857) no continuous replication with doc_ids param
[ https://issues.apache.org/jira/browse/COUCHDB-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau resolved COUCHDB-857. - Resolution: Fixed Fix Version/s: 1.2 > no continuous replication with doc_ids param > > > Key: COUCHDB-857 > URL: https://issues.apache.org/jira/browse/COUCHDB-857 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.11.1, 0.11.2, 0.11.3, 1.0, 1.0.1, 1.0.2 >Reporter: Benoit Chesneau > Fix For: 1.2 > > > I investigated more on this problem : > http://markmail.org/message/bazjkhmwcrdp3kcf > I've found that that *continuous* replication isn't possible with "doc_ids" > parameter. I confirmed this reading the code : > DocIds = couch_util:get_value(<<"doc_ids">>, PostProps, nil), > > ... snip ... > case DocIds of > List when is_list(List) -> > % Fast replication using only a list of doc IDs to replicate. > % Replication sessions, checkpoints and logs are not created > % since the update sequence number of the source DB is not used > % for determining which documents are copied into the target DB. > > . snip > _ -> > % Replication using the _changes API (DB sequence update numbers). > Why can't we have continuous replication with "doc_ids" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-857) no continuous replication with doc_ids param
[ https://issues.apache.org/jira/browse/COUCHDB-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-857: Fix Version/s: 1.1 > no continuous replication with doc_ids param > > > Key: COUCHDB-857 > URL: https://issues.apache.org/jira/browse/COUCHDB-857 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.11.1, 0.11.2, 0.11.3, 1.0, 1.0.1, 1.0.2 >Reporter: Benoit Chesneau > Fix For: 1.1, 1.2 > > > I investigated more on this problem : > http://markmail.org/message/bazjkhmwcrdp3kcf > I've found that that *continuous* replication isn't possible with "doc_ids" > parameter. I confirmed this reading the code : > DocIds = couch_util:get_value(<<"doc_ids">>, PostProps, nil), > > ... snip ... > case DocIds of > List when is_list(List) -> > % Fast replication using only a list of doc IDs to replicate. > % Replication sessions, checkpoints and logs are not created > % since the update sequence number of the source DB is not used > % for determining which documents are copied into the target DB. > > . snip > _ -> > % Replication using the _changes API (DB sequence update numbers). > Why can't we have continuous replication with "doc_ids" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-857) no continuous replication with doc_ids param
[ https://issues.apache.org/jira/browse/COUCHDB-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058861#comment-13058861 ] Filipe Manana commented on COUCHDB-857: --- Yep, this was added in 1.1.0 in fact. > no continuous replication with doc_ids param > > > Key: COUCHDB-857 > URL: https://issues.apache.org/jira/browse/COUCHDB-857 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.11.1, 0.11.2, 0.11.3, 1.0, 1.0.1, 1.0.2 >Reporter: Benoit Chesneau > > I investigated more on this problem : > http://markmail.org/message/bazjkhmwcrdp3kcf > I've found that that *continuous* replication isn't possible with "doc_ids" > parameter. I confirmed this reading the code : > DocIds = couch_util:get_value(<<"doc_ids">>, PostProps, nil), > > ... snip ... > case DocIds of > List when is_list(List) -> > % Fast replication using only a list of doc IDs to replicate. > % Replication sessions, checkpoints and logs are not created > % since the update sequence number of the source DB is not used > % for determining which documents are copied into the target DB. > > . snip > _ -> > % Replication using the _changes API (DB sequence update numbers). > Why can't we have continuous replication with "doc_ids" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1210) files starting with underscore can be attached but not updated
files starting with underscore can be attached but not updated
--
Key: COUCHDB-1210
URL: https://issues.apache.org/jira/browse/COUCHDB-1210
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1
Environment: OSX 10.6 with CouchDB via Brew
Reporter: Nick Fisher
Files that have a name starting with a leading underscore (EG '_foo.txt') can
be attached to a document when it is created, but not when it it updated. I
assume that the create that allows the underscore is in error from what I read
here:
https://github.com/apache/couchdb/blob/trunk/share/www/script/test/attachment_names.js#L77
Example:
$ curl -X POST http://localhost:5984/testdb -H "Content-Type: application/json"
-d '{ "_id": "testing_doc", "_attachments": { "_id": { "data":
"X2Rlc2lnbi9jb25hbgo=", "content_type": "application/octet-stream" } } }'
{"ok":true,"id":"testing_doc","rev":"1-86408f7d442563ec03ffb57c0226ccec"}
$ curl -X PUT http://localhost:5984/conan/testing_doc -H "Content-Type:
application/json" -d '{ "_id": "testing_doc",
"rev":"1-86408f7d442563ec03ffb57c0226ccec", "_attachments": { "_id": { "data":
"X2Rlc2lnbi9jb25hbgo=", "content_type": "application/octet-stream" } } }'
{"error":"bad_request","reason":"Attachment name can't start with '_'"}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-857) no continuous replication with doc_ids param
[ https://issues.apache.org/jira/browse/COUCHDB-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058822#comment-13058822 ] Benoit Chesneau commented on COUCHDB-857: - mmm I think it was done right after I added the doc_ids filter. At least when I read the code of the new replicator I've found: https://github.com/benoitc/couchdb/blob/master/src/couchdb/couch_api_wrap.erl#L334 Filipe? > no continuous replication with doc_ids param > > > Key: COUCHDB-857 > URL: https://issues.apache.org/jira/browse/COUCHDB-857 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.11.1, 0.11.2, 0.11.3, 1.0, 1.0.1, 1.0.2 >Reporter: Benoit Chesneau > > I investigated more on this problem : > http://markmail.org/message/bazjkhmwcrdp3kcf > I've found that that *continuous* replication isn't possible with "doc_ids" > parameter. I confirmed this reading the code : > DocIds = couch_util:get_value(<<"doc_ids">>, PostProps, nil), > > ... snip ... > case DocIds of > List when is_list(List) -> > % Fast replication using only a list of doc IDs to replicate. > % Replication sessions, checkpoints and logs are not created > % since the update sequence number of the source DB is not used > % for determining which documents are copied into the target DB. > > . snip > _ -> > % Replication using the _changes API (DB sequence update numbers). > Why can't we have continuous replication with "doc_ids" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-604) _changes feed with ?feed=continuous does not return valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson resolved COUCHDB-604.
---
Resolution: Won't Fix
First couchdb committer to reach retirement can take on this and the million
niggling deviations from The Canonical Truth Of HTTP. Or knitting, and the
retiree's option.
> _changes feed with ?feed=continuous does not return valid JSON
> --
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.10
>Reporter: Joscha Feth
>Priority: Trivial
> Fix For: 2.0
>
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-617:
--
Fix Version/s: 0.11.1
1.0
rnewson and I checked. This was fixed just before 1.0 and backported for
0.11.1. Yay bookkeeping.
> Large integers being turned into floats
> ---
>
> Key: COUCHDB-617
> URL: https://issues.apache.org/jira/browse/COUCHDB-617
> Project: CouchDB
> Issue Type: Bug
> Environment: 0.11.0b894112
> Ubuntu Karmic
> standard erlang 13.b.1 package
> xulrunner 1.9.1.6
>Reporter: Brian Candler
>Assignee: Chris Anderson
> Fix For: 0.11.1, 1.0
>
> Attachments: couchdb-test-json.diff
>
>
> Somewhere between the view server and the client, large integer values are
> having .0 appended to make them look like floats.
> This is OK:
> $ curl -X POST -d '{"map":"function(doc) { emit(20,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":20,"value":null},
> {"id":"baz","key":20,"value":null},
> {"id":"foo","key":20,"value":null}
> ]}
> But here's a large integer getting the .0 appended:
> $ curl -X POST -d '{"map":"function(doc) { emit(1262958680124,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":1262958680124.0,"value":null},
> {"id":"baz","key":1262958680124.0,"value":null},
> {"id":"foo","key":1262958680124.0,"value":null}
> ]}
> And some values are getting turned into exponential format:
> $ curl -X POST -d '{"map":"function(doc) { emit(30,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":3.0e+9,"value":null},
> {"id":"baz","key":3.0e+9,"value":null},
> {"id":"foo","key":3.0e+9,"value":null}
> ]}
> It appears to affect integers larger than 2^31, but these are still much
> smaller than the 2^48 mantissa of IEEE double precision (which Javascript
> uses). Hence they should be accurately represented as integers, not floats.
> If I run the view server by itself from the command line, all works properly:
> $ bin/couchjs share/server/main.js
> ["reset"]
> true
> ["add_fun","function(doc) { emit(1262958680124,null); }"]
> true
> ["add_fun","function(doc) { emit(30,null); }"]
> true
> ["map_doc",{}]
> [[[1262958680124,null]], [[30,null]]]
> Therefore it looks like the problem is in the Erlang JSON deserialisation
> side. i.e. it's not keeping these values as large integers, when it could be.
> NOTE: I have another machine, running a similar recent couchdb trunk
> (0.11.0b894828) plus Ubuntu Karmic Server Edition built against libmozjs
> 1.8.1.16 (not xulrunner). This exhibits the same behaviour as above.
> But the problem *doesn't* appear on another, older CouchDB installation I
> have. This is 0.11.0a813819 running under Ubuntu Hardy, with erlang 12.b.5
> and libmozjs 1.8.1.18
> {"total_rows":1,"offset":0,"rows":[
> {"id":"person","key":30,"value":null}
> ]}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-604) _changes feed with ?feed=continuous does not return valid JSON
[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-604:
--
Fix Version/s: 2.0
If someone else wants to close this as "Won't Fix", be my guest as that seems
to be the consensus.
I'm taking the uncontroversial stance of setting "Fix Version" as 2.0 so we can
revisit this (if we want) and hopefully it doesn't remain open indefinitely.
> _changes feed with ?feed=continuous does not return valid JSON
> --
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.10
>Reporter: Joscha Feth
>Priority: Trivial
> Fix For: 2.0
>
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-617) Large integers being turned into floats
[
https://issues.apache.org/jira/browse/COUCHDB-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds resolved COUCHDB-617.
---
Resolution: Fixed
I verified that this is no longer occurring at least as of 1.0.1. I didn't
check further back.
> Large integers being turned into floats
> ---
>
> Key: COUCHDB-617
> URL: https://issues.apache.org/jira/browse/COUCHDB-617
> Project: CouchDB
> Issue Type: Bug
> Environment: 0.11.0b894112
> Ubuntu Karmic
> standard erlang 13.b.1 package
> xulrunner 1.9.1.6
>Reporter: Brian Candler
>Assignee: Chris Anderson
> Attachments: couchdb-test-json.diff
>
>
> Somewhere between the view server and the client, large integer values are
> having .0 appended to make them look like floats.
> This is OK:
> $ curl -X POST -d '{"map":"function(doc) { emit(20,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":20,"value":null},
> {"id":"baz","key":20,"value":null},
> {"id":"foo","key":20,"value":null}
> ]}
> But here's a large integer getting the .0 appended:
> $ curl -X POST -d '{"map":"function(doc) { emit(1262958680124,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":1262958680124.0,"value":null},
> {"id":"baz","key":1262958680124.0,"value":null},
> {"id":"foo","key":1262958680124.0,"value":null}
> ]}
> And some values are getting turned into exponential format:
> $ curl -X POST -d '{"map":"function(doc) { emit(30,null); }"}'
> http://127.0.0.1:5984/test_suite_db/_temp_view
> {"total_rows":3,"offset":0,"rows":[
> {"id":"bar","key":3.0e+9,"value":null},
> {"id":"baz","key":3.0e+9,"value":null},
> {"id":"foo","key":3.0e+9,"value":null}
> ]}
> It appears to affect integers larger than 2^31, but these are still much
> smaller than the 2^48 mantissa of IEEE double precision (which Javascript
> uses). Hence they should be accurately represented as integers, not floats.
> If I run the view server by itself from the command line, all works properly:
> $ bin/couchjs share/server/main.js
> ["reset"]
> true
> ["add_fun","function(doc) { emit(1262958680124,null); }"]
> true
> ["add_fun","function(doc) { emit(30,null); }"]
> true
> ["map_doc",{}]
> [[[1262958680124,null]], [[30,null]]]
> Therefore it looks like the problem is in the Erlang JSON deserialisation
> side. i.e. it's not keeping these values as large integers, when it could be.
> NOTE: I have another machine, running a similar recent couchdb trunk
> (0.11.0b894828) plus Ubuntu Karmic Server Edition built against libmozjs
> 1.8.1.16 (not xulrunner). This exhibits the same behaviour as above.
> But the problem *doesn't* appear on another, older CouchDB installation I
> have. This is 0.11.0a813819 running under Ubuntu Hardy, with erlang 12.b.5
> and libmozjs 1.8.1.18
> {"total_rows":1,"offset":0,"rows":[
> {"id":"person","key":30,"value":null}
> ]}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-635) A document with a field named 'constructor' causes it to silently be excluded from any and all map views
[
https://issues.apache.org/jira/browse/COUCHDB-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds resolved COUCHDB-635.
---
Resolution: Fixed
Fix Version/s: 0.11
According to Chris' last comment this was fixed in 0.11 but no one closed the
ticket. I haven't gone back to check 0.11 for sure but 1.0.1 and beyond
definitely doesn't have this problem.
> A document with a field named 'constructor' causes it to silently be excluded
> from any and all map views
>
>
> Key: COUCHDB-635
> URL: https://issues.apache.org/jira/browse/COUCHDB-635
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 0.10.1
> Environment: Mac OS X 10.6.2, CouchDB 0.10.1
>Reporter: James Cash
>Priority: Minor
> Fix For: 0.11
>
>
> If a document has a (nested) field named 'constructor', any map which
> attempts to emit the document will instead silently discard it.
> For example, the document
> { "_id": "CSC190H1S",
>"_rev": "32-287eec55e59305ee94129a0be940bf41",
> "outcomes": {
>"constructor": [
>"knowledge"
>]
> }
> }
> will silently be excluded by any view which attempts to emit "doc" or
> "doc.outcomes" .
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-257) HTTP caching headers don't provide expected behaviour
[ https://issues.apache.org/jira/browse/COUCHDB-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds resolved COUCHDB-257. --- Resolution: Won't Fix No activity in almost nine months and only a problem on IE6, which is quickly (thankfully) fading into obscurity[1]. [1] http://www.w3schools.com/browsers/browsers_explorer.asp > HTTP caching headers don't provide expected behaviour > - > > Key: COUCHDB-257 > URL: https://issues.apache.org/jira/browse/COUCHDB-257 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface >Affects Versions: 0.8.1, 0.9 > Environment: Server: Ubuntu Hardy on x86. Client: Windows XP (32-bit). >Reporter: Vinay Sajip >Priority: Minor > Attachments: caching-header-patch.diff, expires.patch > > > The HTTP caching headers currently put out cause IE (for example) to not > display information correctly in Futon. It's easy to reproduce: I open > windows in Firefox and IE simultaneously, do an update using Firefox (e.g. > add a new document) and refresh the IE window. The updated document count is > not shown. If I clear the browser cache and try again, the updated > information is displayed. The HTTP header put out is > Cache-Control: must-revalidate > which seems to me insufficient - for IE, at least. Is there way of > configuring these headers, to for example > Cache-Control: no-cache > Pragma: no-cache > Expires: some date in the past, or the same value as the Date: header > Christopher Lenz has said about this that "This is due to extra-aggressive > (and against the HTTP spec) caching that IE does on XMLHTTPRequests. A > patch would need to do user agent sniffing to conditionally add the "cache: > false" parameter to the jQuery ajax() invocations in jquery.couch.js (and > maybe elsewhere). I wouldn't want to add this for all user agents, as it > basically circumvents any caching for AJAX requests (even for > not-craptastically-broken implementations), and thus would add quite a bit > of unnecessary overhead." > To this, I would comment that I don't believe a patch to the client-side code > in Futon would be sufficient. There are other clients out there, some of > which will be on Windows and so by default use the (acknowledgely broken) > Microsoft stack. In my view it is more important to err on the side of > correctness than performance - so I believe the headers generated server-side > need to change, as well as perhaps Futon client-side changes. > I note that handle_uuids_req in couch_httpd_misc_handlers.erl uses the > no-cache/Expires scheme I mention. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-857) no continuous replication with doc_ids param
[ https://issues.apache.org/jira/browse/COUCHDB-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058798#comment-13058798 ] Randall Leeds commented on COUCHDB-857: --- Since the built in doc ids filter has been added it should be easy to do this automatically from the request body of an unfiltered replication. Benoit: do you want to implement this? Otherwise close as "Won't Fix" in favor of the filter. > no continuous replication with doc_ids param > > > Key: COUCHDB-857 > URL: https://issues.apache.org/jira/browse/COUCHDB-857 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.11.1, 0.11.2, 0.11.3, 1.0, 1.0.1, 1.0.2 >Reporter: Benoit Chesneau > > I investigated more on this problem : > http://markmail.org/message/bazjkhmwcrdp3kcf > I've found that that *continuous* replication isn't possible with "doc_ids" > parameter. I confirmed this reading the code : > DocIds = couch_util:get_value(<<"doc_ids">>, PostProps, nil), > > ... snip ... > case DocIds of > List when is_list(List) -> > % Fast replication using only a list of doc IDs to replicate. > % Replication sessions, checkpoints and logs are not created > % since the update sequence number of the source DB is not used > % for determining which documents are copied into the target DB. > > . snip > _ -> > % Replication using the _changes API (DB sequence update numbers). > Why can't we have continuous replication with "doc_ids" ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-529) Avoiding updating a doc's _rev if nothing changed
[ https://issues.apache.org/jira/browse/COUCHDB-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds resolved COUCHDB-529. --- Resolution: Won't Fix No activity in almost nine months. Last comment suggests it's prohibitively expensive to implement this logic. > Avoiding updating a doc's _rev if nothing changed > - > > Key: COUCHDB-529 > URL: https://issues.apache.org/jira/browse/COUCHDB-529 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Matt Goodall > > Would it be possible for CouchDB to use its deterministic rev algorithm to > avoid writing changes to the database if nothing has actually changed in the > doc that is sent for update. > The most obvious use case is the user who clicks an HTML form's submit > button, instead of using the back button, when they haven't changed anything. > I suspect most applications do not check if the user made any changes and > therefore end up sending exactly the same data back as an update ... > unnecessarily creating a new document rev, growing the database, invalidating > views, triggering _changes updates, etc. > If CouchDB could determine that the new document is the same as the old > document then it could avoid writing to disc and return the current _rev in > the response. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1123) Longpolling changes feed with filter and accidental Content-Length header stalls
[
https://issues.apache.org/jira/browse/COUCHDB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds updated COUCHDB-1123:
---
Issue Type: Sub-task (was: Bug)
Parent: COUCHDB-735
> Longpolling changes feed with filter and accidental Content-Length header
> stalls
>
>
> Key: COUCHDB-1123
> URL: https://issues.apache.org/jira/browse/COUCHDB-1123
> Project: CouchDB
> Issue Type: Sub-task
> Components: HTTP Interface
>Affects Versions: 1.0.2
> Environment: Mac OS X Snow Leopard, Ubuntu 10.10.
>Reporter: Jyrki Pulliainen
>Priority: Minor
> Labels: changes, contentlength, couchdb, header, http
>
> CouchDB behaves erroneously when doing a GET request with Content-Length
> header to long polling changes feed with filter set.
> Easiest way to reproduce:
> 1. Create a new DB
> 2. Create a single design doc with a filter that just returns true
> 3. Query database with curl: curl -v -H "Content-Length: 123"
> http://localhost:5984/database/_changes?feed=longpoll&filter=designdoc/filter
> At this point CouchDB behaves strangely. It does not wait for the client to
> feed the Content-Length bytes of content (which I think is correct, since GET
> should not have payload), instead, it returns 200 OK and starts the response
> with '{"results":['. However, no changes done to database ever get emitted
> and the connection never gets closed, not even if explicit timeout is set
> upon the request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1209) Unable to set continuous replication from server to local machine. Continuous replication from local to server is working fine.
[
https://issues.apache.org/jira/browse/COUCHDB-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bathineni venkatesh updated COUCHDB-1209:
-
Description:
I am getting following error when i try to set continuous replication from
remote to local.
normal replication(without continuous) is working fine in all cases.
My server is on HTTPS using ssl.
local to remote continuous replication is working fine and remote to local
non-continuous replication is also working fine.
Uncaught error in HTTP request: {error,
{case_clause,
{error,
{{{badmatch,
{error,
changes_timeout}},
[{couch_rep,
do_init,1},
{couch_rep,init,1},
{gen_server,
init_it,6},
{proc_lib,
init_p_do_apply,
3}]},
{child,undefined,
"1057588bc32c0b6adc63b437740da4d5+continuous",
{gen_server,
start_link,
[couch_rep,
["1057588bc32c0b6adc63b437740da4d5",
{[{<<"source">>,
<<"https://admin:*@server:port/databasetoreplicate";>>},
{<<"target">>,
<<"databasetoreplicate">>},
{<<"continuous">>,
true}]},
{user_ctx,
<<"admin">>,
[<<"_admin">>],
<<"{couch_httpd_auth, cookie_authentication_handler}">>}],
[]]},
temporary,1,worker,
[couch_rep]}
was:
I am getting following error when i try to set continuous replication from
remote to local.
normal replication(without continuous) is working fine in all cases.
My server is on HTTPS using ssl.
local to remote continuous replication is working fine and remote to local
non-continuous replication is also working fine.
Uncaught error in HTTP request: {error,
{case_clause,
{error,
{{{badmatch,
{error,
changes_timeout}},
[{couch_rep,
do_init,1},
{couch_rep,init,1},
{gen_server,
init_it,6},
{proc_lib,
init_p_do_apply,
3}]},
{child,undefined,
"1057588bc32c0b6adc63b437740da4d5+continuous",
{gen_server,
start_link,
[couch_rep,
["1057588bc32c0b6adc63b437740da4d5",
[jira] [Created] (COUCHDB-1209) Unable to set continuous replication from server to local machine. Continuous replication from local to server is working fine.
Unable to set continuous replication from server to local machine. Continuous
replication from local to server is working fine.
---
Key: COUCHDB-1209
URL: https://issues.apache.org/jira/browse/COUCHDB-1209
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Environment: Futon. Couch Db 1.1 with Erl R14B03
Reporter: bathineni venkatesh
I am getting following error when i try to set continuous replication from
remote to local.
normal replication(without continuous) is working fine in all cases.
My server is on HTTPS using ssl.
local to remote continuous replication is working fine and remote to local
non-continuous replication is also working fine.
Uncaught error in HTTP request: {error,
{case_clause,
{error,
{{{badmatch,
{error,
changes_timeout}},
[{couch_rep,
do_init,1},
{couch_rep,init,1},
{gen_server,
init_it,6},
{proc_lib,
init_p_do_apply,
3}]},
{child,undefined,
"1057588bc32c0b6adc63b437740da4d5+continuous",
{gen_server,
start_link,
[couch_rep,
["1057588bc32c0b6adc63b437740da4d5",
{[{<<"source">>,
<<"https://admin:4dm1n@85.234.138.103:444/databasetoreplicate";>>},
{<<"target">>,
<<"databasetoreplicate">>},
{<<"continuous">>,
true}]},
{user_ctx,
<<"edge10">>,
[<<"_admin">>],
<<"{couch_httpd_auth, cookie_authentication_handler}">>}],
[]]},
temporary,1,worker,
[couch_rep]}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
