Searched +hist:6 +hist:c5a22e7 (Results 1 - 9 of 9) sorted by relevance
/5.5.2/couchdb/bin/ | ||
H A D | couchdb.bat.tpl.in | diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
H A D | couchdb.tpl.in | diff 6a6a8194 Sat May 22 22:28:09 UTC 2010 Jan Lehnardt <jan@apache.org> fix utils/run git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@947343 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
/5.5.2/couchdb/src/couch_dcp/src/ | ||
H A D | couch_dcp.app.src | diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
H A D | cb_auth_info.erl | diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
/5.5.2/couchdb/src/couch_index_merger/include/ | ||
H A D | couch_view_merger.hrl | diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
H A D | couch_index_merger.hrl | diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 3b80357a Thu Jun 30 10:39:59 UTC 2011 Filipe David Manana <fdmanana@apache.org> Add view merging feature This feature allows for merging view streams from several local and remote databases. For map views, the source databases do not need to have the same map function code, that is, we can merge arbitry map-only views. For reduce views however, all the source databases must have exactly the same reduce function code. This is a necessary restriction due to the rereduce operations that might be needed during the merge phase. However, it a "rereduce" parameter is supplied, which is a string encoding a rereduce function, it's possible to combine/merge arbitrary reduce views. Bear in mind however that combining values originated by different reduce functions can yield unexpected results sometimes. The optional parameter "language" can also be supplied, which tells the server in which language the rereduce function is written (defaults to "javascript" if ommitted). This feature is exposed via the URI /_view_merge/ and accepts all the query parameters that regular view URIs accept (except for ?update_seq=true, which is not yet implemented). E.g. $ curl -H 'Content-Type: application/json' -X POST \ http://localhost:5984/_view_merge \ -d '{"views": { \ "test_db_1": "test/mapview", "http://myserver:5984/test_db_2": "test2/mapview2", "test_db_3": "test3/mapview3" }}' {"total_rows":20,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"id":"5","key":5,"value":"5"}, {"id":"6","key":6,"value":"6"}, {"id":"7","key":7,"value":"7"}, {"id":"8","key":8,"value":"8"}, {"id":"9","key":9,"value":"9"}, {"id":"10","key":10,"value":"10"}, {"id":"11","key":11,"value":"11"}, {"id":"12","key":12,"value":"12"}, {"id":"13","key":13,"value":"13"}, {"id":"14","key":14,"value":"14"}, {"id":"15","key":15,"value":"15"}, {"id":"16","key":16,"value":"16"}, {"id":"17","key":17,"value":"17"}, {"id":"18","key":18,"value":"18"}, {"id":"19","key":19,"value":"19"}, {"id":"20","key":20,"value":"20"} ]} The HTTP GET verb is also supported (query with ?views=encoded_json_object). The view merging spec object can also describe a chained view merging strategy, allowing for a multi level tree structured view merging. This specification is done by nesting view spec objects inside view spec objects. Example: { "views": { "test_db_a": "test/redview1", "http://serverB:5984/_view_merge": { "views": { "test_db_b": "test/redview2", "http://foobar:5985/test_db_c": "test/redview3" } } } } There's also support for a policy about what to do when streaming from a remote server fails. This policy is specified the query parameter "on_error" which can have 2 possible values: "continue" or "stop". "continue" means that if streaming from a remote server fails (whether at the beginning or in the middle), we continue feeding the client with view results from the other souces and add a JSON view row which indicates there was an error streaming from that particular source, example: {"total_rows":50,"rows":[ {"id":"1","key":1,"value":"1"}, {"id":"2","key":2,"value":"2"}, {"id":"3","key":3,"value":"3"}, {"id":"4","key":4,"value":"4"}, {"error": true, "from": "http://myserver:5984/mydb", "reason": "timeout"} {"id":"6","key":6,"value":"6"}, (....) ]} The "stop" policy means that when we get an error while streaming from a remote server we stop the view merging process and the last row sent to the client is an error signaling row like the one given in the previous example. There's also a parameter "connection_timeout" (value in milliseconds) that can be specified per /_view_merge/ request. It defaults to 10s. Change-Id: I49c06fae8198a7e9d32bc4f62a0037866e8c17a2 Reviewed-on: http://review.couchbase.org/7655 Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com> diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
/5.5.2/couchdb/src/couchdb/ | ||
H A D | couch.app.tpl.in | diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
H A D | couch_app.erl | 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 |
H A D | couch_server.erl | diff 6ae13b5f Thu Sep 30 12:03:15 UTC 2010 Filipe David Borba Manana <fdmanana@apache.org> Removing ?getv macros. With OTP releases up to R13B03 it's not possible to define a 2 macro functions with the same name and different arities. (Only allowed in R13B04 and R14). git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@1003025 13f79535-47bb-0310-9956-ffa450edef68 diff 6c6db011 Mon Sep 27 19:14:37 UTC 2010 Filipe David Borba Manana <fdmanana@apache.org> Replacing calls to couch_util:get_value with ?getv git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@1001879 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6c5a22e7 Sun Aug 30 17:56:56 UTC 2009 Adam Kocoloski <kocolosk@apache.org> refactor CouchDB startup procedure, see COUCHDB-216 for details git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@809392 13f79535-47bb-0310-9956-ffa450edef68 diff 6cc0a3fc Thu Dec 18 20:30:24 UTC 2008 Damien F. Katz <damien@apache.org> Fixed problem when a crashed db can cause couch_server to crash when it attempts to interact with it. Moved the interaction from couch_server into the caller's process. git-svn-id: https://svn.apache.org/repos/asf/couchdb/trunk@727811 13f79535-47bb-0310-9956-ffa450edef68 |
Completed in 89 milliseconds