[jira] Reopened: (COUCHDB-491) Support replication over SSL
[ https://issues.apache.org/jira/browse/COUCHDB-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn reopened COUCHDB-491: - Actually this is still not working in 1.0.1 or trunk. Filipe is working on this, but it does not seem this was ever really fixed before. > Support replication over SSL > > > Key: COUCHDB-491 > URL: https://issues.apache.org/jira/browse/COUCHDB-491 > Project: CouchDB > Issue Type: Improvement >Reporter: eric casteleijn > Fix For: 0.10 > > > CouchDB currently does not support replication over SSL which is a problem > when replicating non public databases between two CouchDB servers over the > internet. > It seems SSL support is almost there, though: > If ssl is started from bin/couchdb, push replication to a couchdb that is > behind an SSL proxy works (i.e. to an https:// url), but pull replication > from same fails, because apparently the request is not encrypted at all. (At > least nginx seemed to think it wasn't.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-647) Zero size DB files are created, which make CouchDB crash.
[ https://issues.apache.org/jira/browse/COUCHDB-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn updated COUCHDB-647: Attachment: couch_file_logging.patch Written by Chris Anderson, so he should be the one to grant license. > Zero size DB files are created, which make CouchDB crash. > - > > Key: COUCHDB-647 > URL: https://issues.apache.org/jira/browse/COUCHDB-647 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9.1, 0.10 > Environment: Ubuntu Hardy >Reporter: eric casteleijn >Priority: Critical > Attachments: couch_file_logging.patch > > > Our production server crashed with the following fragment in the error log > http://friendpaste.com/3VfsxGrH2XxvkqE3XQA4oy > It appears that this is due to a corrupted or zero size database file. > Chris Anderson suggested the attached patch to improve the logging in this > case. > doppler came up with a script that reproduces the crash: > touch > /Applications/CouchDBX-0.10.1-R13B03-Leopard.app/Contents/Resources/couchdbx-core/couchdb/var/lib/couchdb/test.couch > while true ; do curl -X GET http://localhost:5984/test ; done > NOTE: On the server that crashed we do not manipulate database files in any > other way than calling the REST interface, so it is still a mystery how zero > sized dbs get created. I will investigate by digging through the logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-647) Zero size DB files are created, which make CouchDB crash.
Zero size DB files are created, which make CouchDB crash. - Key: COUCHDB-647 URL: https://issues.apache.org/jira/browse/COUCHDB-647 Project: CouchDB Issue Type: Bug Affects Versions: 0.9.1, 0.10 Environment: Ubuntu Hardy Reporter: eric casteleijn Priority: Critical Our production server crashed with the following fragment in the error log http://friendpaste.com/3VfsxGrH2XxvkqE3XQA4oy It appears that this is due to a corrupted or zero size database file. Chris Anderson suggested the attached patch to improve the logging in this case. doppler came up with a script that reproduces the crash: touch /Applications/CouchDBX-0.10.1-R13B03-Leopard.app/Contents/Resources/couchdbx-core/couchdb/var/lib/couchdb/test.couch while true ; do curl -X GET http://localhost:5984/test ; done NOTE: On the server that crashed we do not manipulate database files in any other way than calling the REST interface, so it is still a mystery how zero sized dbs get created. I will investigate by digging through the logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-545) speed of couch_config_writer.erl O(n^2) with size of local.ini
[ https://issues.apache.org/jira/browse/COUCHDB-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn updated COUCHDB-545: Attachment: couch_config_writer.erl > speed of couch_config_writer.erl O(n^2) with size of local.ini > -- > > Key: COUCHDB-545 > URL: https://issues.apache.org/jira/browse/COUCHDB-545 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.10, 0.10.1, 0.11 >Reporter: eric casteleijn > Fix For: 0.10, 0.10.1, 0.11 > > Attachments: couch_config_writer.erl > > > PUT requests to _config slow down dramatically as the size of local.ini grows. > Attached version of couch_config_writer.erl (written by Gustavo Niemeyer) > takes the write time to the config file from O(n**2) to O(n) resulting in > dramatic speedups when the size of local.ini grows to non trivial sizes. > (change from 5 minutes to 2 seconds observed on our server.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-545) speed of couch_config_writer.erl O(n^2) with size of local.ini
speed of couch_config_writer.erl O(n^2) with size of local.ini -- Key: COUCHDB-545 URL: https://issues.apache.org/jira/browse/COUCHDB-545 Project: CouchDB Issue Type: Bug Affects Versions: 0.10, 0.10.1, 0.11 Reporter: eric casteleijn Fix For: 0.10, 0.10.1, 0.11 PUT requests to _config slow down dramatically as the size of local.ini grows. Attached version of couch_config_writer.erl (written by Gustavo Niemeyer) takes the write time to the config file from O(n**2) to O(n) resulting in dramatic speedups when the size of local.ini grows to non trivial sizes. (change from 5 minutes to 2 seconds observed on our server.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-540) oauth_token_users seems to be in the wrong place
[ https://issues.apache.org/jira/browse/COUCHDB-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769262#action_12769262 ] eric casteleijn commented on COUCHDB-540: - The /users database would be an excellent place to store these, but the current implementation does not do that yet. A separate local_users.ini would be an improvement, but a minor one IMO. > oauth_token_users seems to be in the wrong place > > > Key: COUCHDB-540 > URL: https://issues.apache.org/jira/browse/COUCHDB-540 > Project: CouchDB > Issue Type: Bug > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu Linux >Reporter: Chris Jones > > If one has many users, the oath_token_users section of /etc/couchdb/local.ini > becomes quite large. This: > a) makes legitimate configuration of the server less friendly > b) makes the file extremely hard to manage via version control > c) is probably a violation of the FHS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-540) oauth_token_users seems to be in the wrong place
[ https://issues.apache.org/jira/browse/COUCHDB-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769249#action_12769249 ] eric casteleijn commented on COUCHDB-540: - I can confirm this is problematic for large numbers of users. The same goes for oauth_token_secrets. > oauth_token_users seems to be in the wrong place > > > Key: COUCHDB-540 > URL: https://issues.apache.org/jira/browse/COUCHDB-540 > Project: CouchDB > Issue Type: Bug > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu Linux >Reporter: Chris Jones > > If one has many users, the oath_token_users section of /etc/couchdb/local.ini > becomes quite large. This: > a) makes legitimate configuration of the server less friendly > b) makes the file extremely hard to manage via version control > c) is probably a violation of the FHS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-498) .ini file chaining not properly reset by -n switch
[ https://issues.apache.org/jira/browse/COUCHDB-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753322#action_12753322 ] eric casteleijn commented on COUCHDB-498: - This fixes the issue for me on the 0.10 branch, thanks so much, Adam! > .ini file chaining not properly reset by -n switch > -- > > Key: COUCHDB-498 > URL: https://issues.apache.org/jira/browse/COUCHDB-498 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.10 > Environment: Ubuntu Linux 09.10 (karmic) unreleased >Reporter: eric casteleijn > Fix For: 0.10 > > Attachments: background_start_config_reset.patch > > > I've added as line 220 in /usr/bin/couchdb: > echo "startarguments: $start_arguments" > Now, when I do: > /usr/bin/couchdb -n -a > /tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini -p > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.pid -o > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stdout -e > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stderr -b > I get: > Apache CouchDB has started, time to relax. > e...@thelog:~$ startarguments: \"/etc/couchdb/default.ini\", > \"/etc/couchdb/local.ini\", \""/etc/couchdb/default.ini"\", > \""/tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini"\" > which suggests to me that the -n switch in this case does not actually reset > the .ini chain. > This came to light when I noticed that any admin users I added in my system > CouchDB also affected any other CouchDB I ran on the same machine. Which > seems logical if my analysis of the bug is correct, since the admin users > would be stored in /etc/couchdb/local.ini which is always picked up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-498) .ini file chaining not properly reset by -n switch
[ https://issues.apache.org/jira/browse/COUCHDB-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752724#action_12752724 ] eric casteleijn commented on COUCHDB-498: - I manually applied the two changes it as best I could against my installed couch (by editing /usr/bin/couchdb directly, probably not the smartest idea) but that showed zero difference. Can you confirm that "-n -a some.ini" really completely bypasses all the .ini files in /etc/couchdb/ ? > .ini file chaining not properly reset by -n switch > -- > > Key: COUCHDB-498 > URL: https://issues.apache.org/jira/browse/COUCHDB-498 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.10 > Environment: Ubuntu Linux 09.10 (karmic) unreleased >Reporter: eric casteleijn > Fix For: 0.10 > > Attachments: background_start_config_reset.patch > > > I've added as line 220 in /usr/bin/couchdb: > echo "startarguments: $start_arguments" > Now, when I do: > /usr/bin/couchdb -n -a > /tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini -p > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.pid -o > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stdout -e > /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stderr -b > I get: > Apache CouchDB has started, time to relax. > e...@thelog:~$ startarguments: \"/etc/couchdb/default.ini\", > \"/etc/couchdb/local.ini\", \""/etc/couchdb/default.ini"\", > \""/tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini"\" > which suggests to me that the -n switch in this case does not actually reset > the .ini chain. > This came to light when I noticed that any admin users I added in my system > CouchDB also affected any other CouchDB I ran on the same machine. Which > seems logical if my analysis of the bug is correct, since the admin users > would be stored in /etc/couchdb/local.ini which is always picked up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-498) .ini file chaining not properly reset by -n switch
.ini file chaining not properly reset by -n switch -- Key: COUCHDB-498 URL: https://issues.apache.org/jira/browse/COUCHDB-498 Project: CouchDB Issue Type: Bug Affects Versions: 0.10 Environment: Ubuntu Linux 09.10 (karmic) unreleased Reporter: eric casteleijn Fix For: 0.10 I've added as line 220 in /usr/bin/couchdb: echo "startarguments: $start_arguments" Now, when I do: /usr/bin/couchdb -n -a /tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini -p /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.pid -o /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stdout -e /tmp/tmp871WkT/xdg_cache/desktop-couch/desktop-couchdb.stderr -b I get: Apache CouchDB has started, time to relax. e...@thelog:~$ startarguments: \"/etc/couchdb/default.ini\", \"/etc/couchdb/local.ini\", \""/etc/couchdb/default.ini"\", \""/tmp/tmp871WkT/xdg_config/desktop-couch/desktop-couchdb.ini"\" which suggests to me that the -n switch in this case does not actually reset the .ini chain. This came to light when I noticed that any admin users I added in my system CouchDB also affected any other CouchDB I ran on the same machine. Which seems logical if my analysis of the bug is correct, since the admin users would be stored in /etc/couchdb/local.ini which is always picked up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-491) Support replication over SSL
Support replication over SSL Key: COUCHDB-491 URL: https://issues.apache.org/jira/browse/COUCHDB-491 Project: CouchDB Issue Type: Improvement Reporter: eric casteleijn Fix For: 0.10 CouchDB currently does not support replication over SSL which is a problem when replicating non public databases between two CouchDB servers over the internet. It seems SSL support is almost there, though: If ssl is started from bin/couchdb, push replication to a couchdb that is behind an SSL proxy works (i.e. to an https:// url), but pull replication from same fails, because apparently the request is not encrypted at all. (At least nginx seemed to think it wasn't.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-438) Add per database (OAuth) authentication to couchdb
Add per database (OAuth) authentication to couchdb -- Key: COUCHDB-438 URL: https://issues.apache.org/jira/browse/COUCHDB-438 Project: CouchDB Issue Type: New Feature Affects Versions: 0.10 Reporter: eric casteleijn Fix For: 0.10 In set-ups where a couchdb node holds databases for many different users that are not allowed to see each other's data, it is vital that it is possible to give users separate roles for each database. It would be best if adding new users, and assigning roles to users for specific databases could be done through the http interface, as modifying .ini files becomes unwieldy for large numbers of users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-420) OAuth authentication support (2-legged initially) and cookie-based authentication
[
https://issues.apache.org/jira/browse/COUCHDB-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736012#action_12736012
]
eric casteleijn commented on COUCHDB-420:
-
Great work, Jason!
I've gotten the newest version of the patch working (which I'm sure will be
attached soon.) Getting things to work still required a lot of hand holding, so
I would love to have (and help write) some detailed setup documentation. In
particular:
1. An example oauth.ini and an elaborate description of all the steps it takes
to authenticate against that.
2. An example replication session from the command line (using curl, or python
+ python-oauth or somesuch.) using the credentials created in 1.
3. A description of the process to add new (oauth) authenticated users to a
running couchdb. (If that is currently possible, I think Jan suggested it was.)
> OAuth authentication support (2-legged initially) and cookie-based
> authentication
> -
>
> Key: COUCHDB-420
> URL: https://issues.apache.org/jira/browse/COUCHDB-420
> Project: CouchDB
> Issue Type: New Feature
> Components: HTTP Interface
>Reporter: Jason Davies
> Fix For: 0.10
>
> Attachments: oauth.1.diff
>
>
> This patch adds two-legged OAuth support to CouchDB.
> 1. In order to do this, a couple of changes have been made to the way auth
> handlers are used. Essentially, the patch allows multiple handlers to be
> specified in a comma-separated list in the following in the [httpd] section
> of your .ini config e.g.
> authentication_handlers = {couch_httpd_oauth,
> oauth_authentication_handler}, {couch_httpd_auth,
> default_authentication_handler}
> The handlers are tried in order until one of them successfully authenticates
> and sets user_ctx on the request. Then the request is passed to the main
> handler.
> 2. Now for the OAuth consumer keys and secrets: as Ubuntu need to be able to
> bootstrap this i.e. add tokens without a running CouchDB, I have advised
> creating a new config file in $PREFIX/etc/couchdb/default.d/ called oauth.ini
> or similar. This should get read by CouchDB's startup script when it loads
> its config files (e.g. default.ini and local.ini as well). There are three
> sections available:
> i. [oauth_consumer_secrets] =
> ii. [oauth_token_secrets] =
> iii. [oauth_token_users] =
> The format I've used above is [section name] followed by how the keys and
> values for that section will look on subsequent lines. The secrets are a way
> for the consumer to prove that it owns the corresponding consumer key or
> access token. The mapping of auth tokens to usernames is a way to specify
> which user/roles to give to a consumer with a given access token.
> In the future we will also store tokens in the user database (see below).
> 3. OAuth replication. I've extended the JSON sent via POST when initiating a
> replication as follows:
> {
> source: {
>url: ,
>auth: {
> oauth: {
>consumer_key: ,
>consumer_secret: ,
>token_secret: ,
>token:
> }
>}
> },
> target: /* same syntax as source, or string for a URL with no auth info, or
> string for local database name */
> }
> 4. This patch also includes cookie-authentication support to CouchDB. I've
> covered this here:
> http://www.jasondavies.com/blog/2009/05/27/secure-cookie-authentication-couchdb/
> The cookie-authentication branch is being used on a couple of live sites and
> the branch has also been worked on by jchris and benoitc. As well as cookie
> auth it includes the beginnings of support for a per-node user database, with
> APIs for creating/deleting users etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-422) PUT to _local/doc_id creates document '_local'
PUT to _local/doc_id creates document '_local'
--
Key: COUCHDB-422
URL: https://issues.apache.org/jira/browse/COUCHDB-422
Project: CouchDB
Issue Type: Bug
Affects Versions: 0.10
Environment: Ubuntu 9.04
Reporter: eric casteleijn
Priority: Minor
Fix For: 0.10
After davisp's revision r796246 doing a put to a document id like
'_local/doc_id' results in a visible, and apparently non-local document with id
'_local'. When escaping the slash as '%2F' everything works as before, and
expected, i.e. a local document with the above id is created.
To test:
curl -X PUT -d '{"foo": "bar"}' http://127.0.0.1:5987/db1/_local/yokal
result:
{"ok":true,"id":"_local","rev":"1-770307fe8d4210bab8ec65c59983e03c"}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-360) Add global _changes feature
[ https://issues.apache.org/jira/browse/COUCHDB-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733320#action_12733320 ] eric casteleijn commented on COUCHDB-360: - I would really like to have a global _changes feed, as I anticipate having a lot of databases to deal with in a similar manner. One question though: Is it impossible, inefficient to include more details of the changes? I would really like to at least optionally have the same information available as the per db _changes feed exposes. > Add global _changes feature > --- > > Key: COUCHDB-360 > URL: https://issues.apache.org/jira/browse/COUCHDB-360 > Project: CouchDB > Issue Type: New Feature >Reporter: Robert Newson > Attachments: global_changes.patch > > > Add a global version of _changes to allow monitoring of changes to all > databases. It does not need to include details of the change as clients of > this interface must track update sequences for each database anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-390) proposed additions to _changes feed
proposed additions to _changes feed --- Key: COUCHDB-390 URL: https://issues.apache.org/jira/browse/COUCHDB-390 Project: CouchDB Issue Type: New Feature Reporter: eric casteleijn The _changes comet feed as a replacement for the update notifications is a great step forward, but I'm currently missing these features: 1. The feeds are now per database, rather than per server, which is nice in some use cases, but in others it's preferable to have a server wide feed (In the case of many thousands of databases on a server, and a single process reacting to updates, by putting messages on a message queue for instance). Ideally I'd like to have both server wide and per database _changes feeds available. 2. I'd like to have a configurable _changes feed that let's me declare what data will be output in the update rows in the feed, in a similar way to writing views. 3. I'd like to (optionally) have information on whether a particular update was a document creation, update or deletion, so clients would be able to react to those differently without needing to query into the database to find out what happened. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-194) [startkey, endkey[: provide a right-open range selection method
[
https://issues.apache.org/jira/browse/COUCHDB-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696651#action_12696651
]
eric casteleijn commented on COUCHDB-194:
-
Worth noting:
The builtin "_all_docs_by_seq" view right now returns everything with key:
startkey < key <= endkey
I would like to know what the intended consistent way will be, so that I can
already make my higher level API work that way, and not ahve to break clients'
code when this gets changed/fixed.
> [startkey, endkey[: provide a right-open range selection method
> ---
>
> Key: COUCHDB-194
> URL: https://issues.apache.org/jira/browse/COUCHDB-194
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.10
>Reporter: Maximillian Dornseif
>Priority: Blocker
> Fix For: 0.10
>
>
> While writing something about using CouchDB I came across the issue of "slice
> indexes" (called startkey and endkey in CouchDB lingo).
> I found no exact definition of startkey and endkey anywhere in the
> documentation. Testing reveals that access on _all_docs and on views
> documents are retuned in the interval
> [startkey, endkey] = (startkey <= k <= endkey).
> I don't know if this was a conscious design decision. But I like to promote a
> slightly different interpretation (and thus API change):
> [startkey, endkey[ = (startkey <= k < endkey).
> Both approaches are valid and used in the real world. Ruby uses the inclusive
> ("right-closed" in math speak) first approach:
> >> l = [1,2,3,4]
> >> l.slice(1,2)
> => [2, 3]
> Python uses the exclusive ("right-open" in math speak) second approach:
> >>> l = [1,2,3,4]
> >>> l[1,2]
> [2]
> For array indices both work fine and which one to prefer is mostly an issue
> of habit. In spoken language both approaches are used: "Have the Software
> done until saturday" probably means right-open to the client and right-closed
> to the coder.
> But if you are working with keys that are more than array indexes, then
> right-open is much easier to handle. That is because you have to *guess* the
> biggest value you want to get. The Wiki at
> http://wiki.apache.org/couchdb/View_collation contains an example of that
> problem:
> It is suggested that you use
> startkey="_design/"&endkey="_design/Z"
> or
> startkey="_design/"&endkey="_design/\u″
> to get a list of all design documents - also the replication system in the db
> core uses the same hack.
> This breaks if a design document is named "ZTop" or
> "\Iñtërnâtiônàlizætiøn". Such names might be unlikely but we are computer
> scientists; "unlikely" is a bad approach to software engineering.
> The think what we really want to ask CouchDB is to "get all documents with
> keys starting with '_design/'".
> This is basically impossible to do with right-closed intervals. We could use
> startkey="_design/"&endkey="_design0″ ('0′ is the ASCII character after '/')
> and this will work fine ... until there is actually a document with the key
> "_design0″ in the system. Unlikely, but ...
> To make selection by intervals reliable currently clients have to guess the
> last key (the approach) or use the fist key not to include (the _design0
> approach) and then post process the result to remove the last element
> returned if it exactly matches the given endkey value.
> If couchdb would change to a right-open interval approach post processing
> would go away in most cases. See
> http://blogs.23.nu/c0re/2008/12/building-a-track-and-trace-application-with-couchdb/
> for two real world examples.
> At least for string keys and float keys changing the meaning to [startkey,
> endkey[ would allow selections like
> * "all strings starting with 'abc'"
> * all numbers between 10.5 and 11
> It also would hopefully break not to much existing code. Since the notion of
> endkey seems to be already considered "fishy" (see the Z approach) most
> code seems to try to avoid that issue. For example
> 'startkey="_design/"&endkey="_design/Z"' still would work unless you
> have a design document being named exactly "Z".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-290) Include sequence number in update notifications
[ https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695503#action_12695503 ] eric casteleijn commented on COUCHDB-290: - That is excellent news! If there is any way we can assist with that work (testing, discussion/feedback, documenting on wiki, or coding) please let us know. If this is in the near future, I guess we can live with patching our couch instances for the duration. > Include sequence number in update notifications > --- > > Key: COUCHDB-290 > URL: https://issues.apache.org/jira/browse/COUCHDB-290 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 >Reporter: Elliot Murphy >Priority: Minor > Fix For: 0.10 > > Attachments: couchdb-sequences.patch, couchdb-sequences.patch > > > Hi! There's been requests to include the sequence number when sending an > update notification. Thanks to the guidance from davisp on #couchdb on March > 13th, I've been able to put together a little patch that does just that. In > the future I'm interested in doing the same for the create notification, and > perhaps extending create/delete/update notifications to include a list of > affected doc IDs. > For now though, just this simple patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-290) Include sequence number in update notifications
[ https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694976#action_12694976 ] eric casteleijn commented on COUCHDB-290: - Now that 0.9 has landed, is there any chance this patch could land? I found an issue in our specific use case which make it more that just optimization: we log sequence numbers with timestamps to a file, and getting the sequence number from couch with a request from the update trigger frequently returns a higher sequence number than one would expect, since another update has already happened before the update trigger gets back the sequence number. This can be coded around, but it makes it *very* hard to write deterministic tests for the update triggers. If there is anything I or Elliot can do to help this patch along, we'd be glad to do it. > Include sequence number in update notifications > --- > > Key: COUCHDB-290 > URL: https://issues.apache.org/jira/browse/COUCHDB-290 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 >Reporter: Elliot Murphy >Priority: Minor > Fix For: 0.10 > > Attachments: couchdb-sequences.patch, couchdb-sequences.patch > > > Hi! There's been requests to include the sequence number when sending an > update notification. Thanks to the guidance from davisp on #couchdb on March > 13th, I've been able to put together a little patch that does just that. In > the future I'm interested in doing the same for the create notification, and > perhaps extending create/delete/update notifications to include a list of > affected doc IDs. > For now though, just this simple patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-290) Include sequence number in update notifications
[ https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682313#action_12682313 ] eric casteleijn commented on COUCHDB-290: - @Jan ah, yes: remembering the last sequence number you got in your last query would solve the problem for some use cases, unfortunately not for ours: we want to track sequence numbers and log them with a timestamp, i.e. we don't want to query the couchdb at all at that particular moment, but possibly at some later date for everything updated between seq_n and seq_m, based on their timestamps. > Include sequence number in update notifications > --- > > Key: COUCHDB-290 > URL: https://issues.apache.org/jira/browse/COUCHDB-290 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 >Reporter: Elliot Murphy >Priority: Minor > Fix For: 0.9 > > Attachments: couchdb-sequences.patch, couchdb-sequences.patch > > > Hi! There's been requests to include the sequence number when sending an > update notification. Thanks to the guidance from davisp on #couchdb on March > 13th, I've been able to put together a little patch that does just that. In > the future I'm interested in doing the same for the create notification, and > perhaps extending create/delete/update notifications to include a list of > affected doc IDs. > For now though, just this simple patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-290) Include sequence number in update notifications
[ https://issues.apache.org/jira/browse/COUCHDB-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682301#action_12682301 ] eric casteleijn commented on COUCHDB-290: - The problem it solves is that for many update triggers, it is important to find out what has changed in the update, which unfortunately means logging sequence numbers outside of couchdb, so that an all_documents_by_seq query?startkey=old_seq can be run to find out which documents have changed. I think this is a pretty common use case. We can of course let each update trigger call fire off a request to the db to get its current seq_no, but that's unfortunate since the information could easily be provided to the update trigger, and by the time the request has returned, the sequence number might have changed again. A list of changed document ids would be even better, but if this is not possible, we will have to do requests for them. Bulk updates aside, this would always be a single document id though, or am I wrong? If there is a way to pass that document id *or* "_bulk" or something, that would solve it for all non-nulk updates at least. I realize that would probably be a more involved patch. > Include sequence number in update notifications > --- > > Key: COUCHDB-290 > URL: https://issues.apache.org/jira/browse/COUCHDB-290 > Project: CouchDB > Issue Type: Improvement >Affects Versions: 0.9 >Reporter: Elliot Murphy >Priority: Minor > Fix For: 0.9 > > Attachments: couchdb-sequences.patch, couchdb-sequences.patch > > > Hi! There's been requests to include the sequence number when sending an > update notification. Thanks to the guidance from davisp on #couchdb on March > 13th, I've been able to put together a little patch that does just that. In > the future I'm interested in doing the same for the create notification, and > perhaps extending create/delete/update notifications to include a list of > affected doc IDs. > For now though, just this simple patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-284) Couchdb can't find main.js when running under a path that contains a directory name starting with two or more dashes
Couchdb can't find main.js when running under a path that contains a directory name starting with two or more dashes Key: COUCHDB-284 URL: https://issues.apache.org/jira/browse/COUCHDB-284 Project: CouchDB Issue Type: Bug Components: Build System, Infrastructure Affects Versions: 0.9 Environment: Ubuntu Linux Reporter: eric casteleijn Priority: Minor When coucdb runs in directory below any directory whose name starts with two or more dashes, say /some/path/---foo/couch It will error when it tries to call main.js with: "could not open script file /path/some/-foo/couch/share/server/main.js" Note that the first two dashes have been dropped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-274) Add a -C option to load configuration file without resetting system default
[ https://issues.apache.org/jira/browse/COUCHDB-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn updated COUCHDB-274: Attachment: couchdb.patch Restored ':' option to -c option. Thanks Noah. > Add a -C option to load configuration file without resetting system default > --- > > Key: COUCHDB-274 > URL: https://issues.apache.org/jira/browse/COUCHDB-274 > Project: CouchDB > Issue Type: New Feature > Components: Infrastructure >Reporter: eric casteleijn >Priority: Minor > Attachments: couchdb.patch > > > I created a patch that adds a -C (as opposed to lowercase -c) option that > accepts one of more configuration files and overrides the system default with > the values specified therein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-274) Add a -C option to load configuration file without resetting system default
[ https://issues.apache.org/jira/browse/COUCHDB-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn updated COUCHDB-274: Attachment: (was: couchdb.patch) > Add a -C option to load configuration file without resetting system default > --- > > Key: COUCHDB-274 > URL: https://issues.apache.org/jira/browse/COUCHDB-274 > Project: CouchDB > Issue Type: New Feature > Components: Infrastructure >Reporter: eric casteleijn >Priority: Minor > > I created a patch that adds a -C (as opposed to lowercase -c) option that > accepts one of more configuration files and overrides the system default with > the values specified therein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-274) Add a -C option to load configuration file without resetting system default
[ https://issues.apache.org/jira/browse/COUCHDB-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eric casteleijn updated COUCHDB-274: Attachment: couchdb.patch > Add a -C option to load configuration file without resetting system default > --- > > Key: COUCHDB-274 > URL: https://issues.apache.org/jira/browse/COUCHDB-274 > Project: CouchDB > Issue Type: New Feature > Components: Infrastructure >Reporter: eric casteleijn >Priority: Minor > Attachments: couchdb.patch > > > I created a patch that adds a -C (as opposed to lowercase -c) option that > accepts one of more configuration files and overrides the system default with > the values specified therein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-274) Add a -C option to load configuration file without resetting system default
Add a -C option to load configuration file without resetting system default --- Key: COUCHDB-274 URL: https://issues.apache.org/jira/browse/COUCHDB-274 Project: CouchDB Issue Type: New Feature Components: Infrastructure Reporter: eric casteleijn Priority: Minor I created a patch that adds a -C (as opposed to lowercase -c) option that accepts one of more configuration files and overrides the system default with the values specified therein. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
