[jira] [Commented] (COUCHDB-1356) POST _session responds with name: null if _admin user and no _users doc present
[
https://issues.apache.org/jira/browse/COUCHDB-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164225#comment-13164225
]
Johannes J. Schmidt commented on COUCHDB-1356:
--
But then why is the name not null when issuing a GET request to _session like I
mentioned above?
I believe the POST response should be according to the GET response.
Btw. the couch I query is not in Admin Party mode.
POST _session responds with name: null if _admin user and no _users doc
present
---
Key: COUCHDB-1356
URL: https://issues.apache.org/jira/browse/COUCHDB-1356
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Johannes J. Schmidt
Priority: Minor
When logging in with admin credentials (and no corresponding _users doc, if
that is important), the response of the POST to _session has the name
property set to null:
{ok:true,name:null,roles:[_admin]}
It should be the name of the admin instead, like it does when logging in with
a standard user:
{ok:true,name:standarduser,roles:[]}
Requesting the _session object after logging in with an admin, the name is
proper set:
{ok:true,userCtx:{name:adminuser,roles:[_admin]},info:{authentication_db:_users,authentication_handlers:[oauth,cookie,default],authenticated:cookie}}
Johannes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 2:51 AM, Jason Smith j...@iriscouch.com wrote: Hi, all. Iris Couch urgently needs improved logging facilities in CouchDB. My goal is to make something we all love and get it accepted upstream, God willing. Or committers willing. But I repeat myself! This is the brainstorming and requirements gathering phase. In the CouchDB of your dreams, logging system fits you like an old pair of sneakers. It's perfect. Now, what characteristics does that system exhibit? I will compile feedback into a spec on the wiki. I hope to avoid bikeshedding. Seriously, please don't even mention a product or project by name. At this phase I hope to stick to descriptions of functionality, goals, and non-goals. I want to evaluate tools later. To start the discussion: logging is viewed differently based on your relationship with CouchDB: 1. Developers of CouchDB 2. Administrators of a couch 3. Application developers My roles are administration, and a little bit of development. Requirements, in no order. * Idiomatic Erlang * Is a compelling place for new people to contribute. Miguel de Icaza talks about this. It's not enough that the source code is public. You have to provide a smooth on-ramp, where people people get great bang for their buck. They write a modest feature, and are rewarded by seeing its effects immediately. In other words: plugins. Or maybe a behaviour. Or some way to swap in formatters and data sinks. I don't want to write a Loggly target (http://loggly.com). Loggly should be begging me to merge their module. * 1st cut, no change to the default behavior. You still get the that peculiar log file you know and love. People are parsing their log files, and might expect version 1.x not to change. * Existing code still works. No sweeping changes hitting every ?LOG_INFO and ?LOG_DEBUG. (Filipe, would you please share your thoughts on these? I think you struggled with the conflict between them recently.) * No performance impact (non-blocking)... * ... but also, impossible or difficult to overwhelm or crash or lose logs. (The next few points sort of fit together) * Logs are not strings, but data structures, with data (the log message) and metadata (severity, line number, maybe the call stack, etc.) * More log levels. Roughly: trace, debug, info, warn, error, fatal * Maybe automatic trace logs upon function entry/exit with return values. Not sure if this is doable. Maybe a compile option, for `make dev` * When you log something, your module, line number, and maybe PID are known * Components or categories, or tags, where multiple .erl files or individual log events can share a common property (http, views, * A policy decides what to do with logs based on level, module, or component. You can set the policy either via configuration or programatically. * There is a formatter API to serialize log data. Built-in formatters include the legacy format, and Jan's Apache httpd combined format. * There is a transport API to receive logs and DTRT. * I know this is insane, but kill -HUP pid should make couch reopen its log files. Okay, I'll settle down now. = Non Goals = * Log rotation. I have never seen a rotation feature in an application which was better than the OS tools. And you can get problem where both the server and the OS are rotating the same logs. I have seen that happen, twice. Or was it once? Of course, people could write a rotating file transport. -- Iris Couch I fully agree, we need better logging in couch. I don't really like the idea of saving any data structures, but why not. Imo such things could be saved as binaries strings and then parse but ... Technically all of these things can be covered wby lagger I think :h https://github.com/basho/lager It handle different backend, attribute supports, logs rotation, tracing, loggers integation .. More on their page. We expect to use it in refuge, and I think I can provide a patch for couch soon as well. - benoît
Re: The perfect logger for development
Don't forgot the request body when it was a PUT/DELETE. Cheers, Volker On 12/07/2011 05:24 AM, Jason Smith wrote: Brilliant, thanks! I think this is possible if the Req object is part of the log object. Then a formatter can access it there. Off the top of my head, it would have access to the source IP address, the HTTP method, the path and query string, and headers. On Wed, Dec 7, 2011 at 10:44 AM, kowsik kow...@gmail.com wrote: As a CouchDB administrator, I would want *all* exception dumps to be prefaced by the inbound request URL with the query parameters (assuming it's a web request that caused the exception). There are case where I've seen a stack trace but couldn't tell which inbound request caused the problem. K. --- http://blitz.io @pcapr On Tue, Dec 6, 2011 at 5:51 PM, Jason Smith j...@iriscouch.com wrote: Hi, all. Iris Couch urgently needs improved logging facilities in CouchDB. My goal is to make something we all love and get it accepted upstream, God willing. Or committers willing. But I repeat myself! This is the brainstorming and requirements gathering phase. In the CouchDB of your dreams, logging system fits you like an old pair of sneakers. It's perfect. Now, what characteristics does that system exhibit? I will compile feedback into a spec on the wiki. I hope to avoid bikeshedding. Seriously, please don't even mention a product or project by name. At this phase I hope to stick to descriptions of functionality, goals, and non-goals. I want to evaluate tools later. To start the discussion: logging is viewed differently based on your relationship with CouchDB: 1. Developers of CouchDB 2. Administrators of a couch 3. Application developers My roles are administration, and a little bit of development. Requirements, in no order. * Idiomatic Erlang * Is a compelling place for new people to contribute. Miguel de Icaza talks about this. It's not enough that the source code is public. You have to provide a smooth on-ramp, where people people get great bang for their buck. They write a modest feature, and are rewarded by seeing its effects immediately. In other words: plugins. Or maybe a behaviour. Or some way to swap in formatters and data sinks. I don't want to write a Loggly target (http://loggly.com). Loggly should be begging me to merge their module. * 1st cut, no change to the default behavior. You still get the that peculiar log file you know and love. People are parsing their log files, and might expect version 1.x not to change. * Existing code still works. No sweeping changes hitting every ?LOG_INFO and ?LOG_DEBUG. (Filipe, would you please share your thoughts on these? I think you struggled with the conflict between them recently.) * No performance impact (non-blocking)... * ... but also, impossible or difficult to overwhelm or crash or lose logs. (The next few points sort of fit together) * Logs are not strings, but data structures, with data (the log message) and metadata (severity, line number, maybe the call stack, etc.) * More log levels. Roughly: trace, debug, info, warn, error, fatal * Maybe automatic trace logs upon function entry/exit with return values. Not sure if this is doable. Maybe a compile option, for `make dev` * When you log something, your module, line number, and maybe PID are known * Components or categories, or tags, where multiple .erl files or individual log events can share a common property (http, views, * A policy decides what to do with logs based on level, module, or component. You can set the policy either via configuration or programatically. * There is a formatter API to serialize log data. Built-in formatters include the legacy format, and Jan's Apache httpd combined format. * There is a transport API to receive logs and DTRT. * I know this is insane, but kill -HUP pid should make couch reopen its log files. Okay, I'll settle down now. = Non Goals = * Log rotation. I have never seen a rotation feature in an application which was better than the OS tools. And you can get problem where both the server and the OS are rotating the same logs. I have seen that happen, twice. Or was it once? Of course, people could write a rotating file transport. -- Iris Couch
Re: The perfect logger for development
Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. More responses inline. On Wed, Dec 7, 2011 at 3:06 PM, Benoit Chesneau bchesn...@gmail.com wrote: I fully agree, we need better logging in couch. I don't really like the idea of saving any data structures, but why not. Imo such things could be saved as binaries strings and then parse but ... I agree. For the first milestone I propose no change to the logs: the same ?LOG_DEBUG() macros, the same text file; the same log format only a mother could love. When I say data structures, I simply mean that more useful information is available to be logged. A first milestone might to output to the same log file as before. However, I hope it would be easy to write different log formatters for different needs: * Web developer format: client IP, method, headers, log message * Erlang troubleshooting format: PID, supervision tree, heap usage, log message For the first milestone, though, something modest: * Traditional format: timestamp, log level, pid, log message // i.e. what Couch does now -- Iris Couch
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. More responses inline. On Wed, Dec 7, 2011 at 3:06 PM, Benoit Chesneau bchesn...@gmail.com wrote: I fully agree, we need better logging in couch. I don't really like the idea of saving any data structures, but why not. Imo such things could be saved as binaries strings and then parse but ... I agree. For the first milestone I propose no change to the logs: the same ?LOG_DEBUG() macros, the same text file; the same log format only a mother could love. When I say data structures, I simply mean that more useful information is available to be logged. ok so you're speaking about log arguments? A first milestone might to output to the same log file as before. However, I hope it would be easy to write different log formatters for different needs: * Web developer format: client IP, method, headers, log message * Erlang troubleshooting format: PID, supervision tree, heap usage, log message well such infos should be natural since the code doesn't hangs at the same place. you don't have the same info then. For the first milestone, though, something modest: * Traditional format: timestamp, log level, pid, log message // i.e. what Couch does now again lagger do a lot of thing about that. Technically I really like its possibilities. And we don't have to reinvent the wheel . I woul dbe curious anyway how cloudant is comparing twig to it. - benoît
Re: The perfect logger for development
ok so you're speaking about log arguments? s/arguments/attributes. (if yes you should really have a look in the lagger readme ;) - benoît
Re: The perfect logger for development
As an app developer, I just appreciate that you discuss this topic. It's really, really hard to me to get useful information out of the current logs. Doesn't make it easy to relax ;-) On Wed, Dec 7, 2011 at 10:52 AM, Benoit Chesneau bchesn...@gmail.comwrote: ok so you're speaking about log arguments? s/arguments/attributes. (if yes you should really have a look in the lagger readme ;) - benoît
[jira] [Updated] (COUCHDB-1357) Authentication failure after updating password in user document
[ https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1357: --- Attachment: 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch Authentication failure after updating password in user document --- Key: COUCHDB-1357 URL: https://issues.apache.org/jira/browse/COUCHDB-1357 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1 Reporter: Filipe Manana Attachments: 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch From the report at the users mailing list: http://s.apache.org/9OG Seems like after updating the password in a user doc, the user is not able to login with the new password unless Couch is restarted. Sounds like a caching issue. The only case of getting the cache consistent with the _users database content is if the _users database processes crash and after the crash user documents are updated. The cache daemon is ignoring the database crash. The following patch updates the daemon to monitor the _users database and crash (letting the supervisor restart it) if the database process crashes. Etap test included. This might be related to COUCHDB-1212. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1357) Authentication failure after updating password in user document
[ https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1357: --- Attachment: (was: COUCHDB-1357-master.patch) Authentication failure after updating password in user document --- Key: COUCHDB-1357 URL: https://issues.apache.org/jira/browse/COUCHDB-1357 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1 Reporter: Filipe Manana Attachments: 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch From the report at the users mailing list: http://s.apache.org/9OG Seems like after updating the password in a user doc, the user is not able to login with the new password unless Couch is restarted. Sounds like a caching issue. The only case of getting the cache consistent with the _users database content is if the _users database processes crash and after the crash user documents are updated. The cache daemon is ignoring the database crash. The following patch updates the daemon to monitor the _users database and crash (letting the supervisor restart it) if the database process crashes. Etap test included. This might be related to COUCHDB-1212. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1357) Authentication failure after updating password in user document
[
https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164343#comment-13164343
]
Filipe Manana commented on COUCHDB-1357:
Pete, I'm not sure this issue relates directly yo your issue.
From the error {error,system_limit, it seems your system reached the maximum
limit of available file descriptors. I have no idea how to increase this limit
on Windows, perhaps Dave can help here.
Authentication failure after updating password in user document
---
Key: COUCHDB-1357
URL: https://issues.apache.org/jira/browse/COUCHDB-1357
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Filipe Manana
Attachments:
0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch
From the report at the users mailing list:
http://s.apache.org/9OG
Seems like after updating the password in a user doc, the user is not able to
login with the new password unless Couch is restarted. Sounds like a caching
issue.
The only case of getting the cache consistent with the _users database
content is if the _users database processes crash and after the crash user
documents are updated. The cache daemon is ignoring the database crash.
The following patch updates the daemon to monitor the _users database and
crash (letting the supervisor restart it) if the database process crashes.
Etap test included.
This might be related to COUCHDB-1212.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The perfect logger for development
One of the things we do in BigCouch is attach a unique identifier to the request also, so that we can correlate a given request with other log messages that may appear from other internal components. We call it an X-Request-ID or some such thing and users can curl -v and tell us what that is. It's great for debugging On Dec 6, 2011, at 11:24 PM, Jason Smith wrote: Brilliant, thanks! I think this is possible if the Req object is part of the log object. Then a formatter can access it there. Off the top of my head, it would have access to the source IP address, the HTTP method, the path and query string, and headers. On Wed, Dec 7, 2011 at 10:44 AM, kowsik kow...@gmail.com wrote: As a CouchDB administrator, I would want *all* exception dumps to be prefaced by the inbound request URL with the query parameters (assuming it's a web request that caused the exception). There are case where I've seen a stack trace but couldn't tell which inbound request caused the problem. K. --- http://blitz.io @pcapr On Tue, Dec 6, 2011 at 5:51 PM, Jason Smith j...@iriscouch.com wrote: Hi, all. Iris Couch urgently needs improved logging facilities in CouchDB. My goal is to make something we all love and get it accepted upstream, God willing. Or committers willing. But I repeat myself! This is the brainstorming and requirements gathering phase. In the CouchDB of your dreams, logging system fits you like an old pair of sneakers. It's perfect. Now, what characteristics does that system exhibit? I will compile feedback into a spec on the wiki. I hope to avoid bikeshedding. Seriously, please don't even mention a product or project by name. At this phase I hope to stick to descriptions of functionality, goals, and non-goals. I want to evaluate tools later. To start the discussion: logging is viewed differently based on your relationship with CouchDB: 1. Developers of CouchDB 2. Administrators of a couch 3. Application developers My roles are administration, and a little bit of development. Requirements, in no order. * Idiomatic Erlang * Is a compelling place for new people to contribute. Miguel de Icaza talks about this. It's not enough that the source code is public. You have to provide a smooth on-ramp, where people people get great bang for their buck. They write a modest feature, and are rewarded by seeing its effects immediately. In other words: plugins. Or maybe a behaviour. Or some way to swap in formatters and data sinks. I don't want to write a Loggly target (http://loggly.com). Loggly should be begging me to merge their module. * 1st cut, no change to the default behavior. You still get the that peculiar log file you know and love. People are parsing their log files, and might expect version 1.x not to change. * Existing code still works. No sweeping changes hitting every ?LOG_INFO and ?LOG_DEBUG. (Filipe, would you please share your thoughts on these? I think you struggled with the conflict between them recently.) * No performance impact (non-blocking)... * ... but also, impossible or difficult to overwhelm or crash or lose logs. (The next few points sort of fit together) * Logs are not strings, but data structures, with data (the log message) and metadata (severity, line number, maybe the call stack, etc.) * More log levels. Roughly: trace, debug, info, warn, error, fatal * Maybe automatic trace logs upon function entry/exit with return values. Not sure if this is doable. Maybe a compile option, for `make dev` * When you log something, your module, line number, and maybe PID are known * Components or categories, or tags, where multiple .erl files or individual log events can share a common property (http, views, * A policy decides what to do with logs based on level, module, or component. You can set the policy either via configuration or programatically. * There is a formatter API to serialize log data. Built-in formatters include the legacy format, and Jan's Apache httpd combined format. * There is a transport API to receive logs and DTRT. * I know this is insane, but kill -HUP pid should make couch reopen its log files. Okay, I'll settle down now. = Non Goals = * Log rotation. I have never seen a rotation feature in an application which was better than the OS tools. And you can get problem where both the server and the OS are rotating the same logs. I have seen that happen, twice. Or was it once? Of course, people could write a rotating file transport. -- Iris Couch -- Iris Couch
Re: [jira] [Commented] (COUCHDB-1357) Authentication failure after updating password in user document
Hi,
As I reply in the users list, since this is an Erlang problem, I think
it can be solved by imposing a higher maximum ports limit with
ERL_MAX_PORTS environment variable or/and +P option at erl command. The
default limit is 1024 and Erlang chose that number for compatibility
with all the operating systems. Maybe it would be a good idea for this
option to be set in the .ini file by the users... (just a suggestion)
I hope this information will help.
Cheers,
CGS
On 12/07/2011 01:04 PM, Filipe Manana (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164343#comment-13164343
]
Filipe Manana commented on COUCHDB-1357:
Pete, I'm not sure this issue relates directly yo your issue.
From the error {error,system_limit, it seems your system reached the maximum
limit of available file descriptors. I have no idea how to increase this limit
on Windows, perhaps Dave can help here.
Authentication failure after updating password in user document
---
Key: COUCHDB-1357
URL: https://issues.apache.org/jira/browse/COUCHDB-1357
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1.1
Reporter: Filipe Manana
Attachments:
0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch
From the report at the users mailing list:
http://s.apache.org/9OG
Seems like after updating the password in a user doc, the user is not able to
login with the new password unless Couch is restarted. Sounds like a caching
issue.
The only case of getting the cache consistent with the _users database content
is if the _users database processes crash and after the crash user documents
are updated. The cache daemon is ignoring the database crash.
The following patch updates the daemon to monitor the _users database and crash
(letting the supervisor restart it) if the database process crashes.
Etap test included.
This might be related to COUCHDB-1212.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1357) Authentication failure after updating password in user document
[ https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164378#comment-13164378 ] Filipe Manana commented on COUCHDB-1357: Pete, there's this Erlang thread (Increase the handle limit) Dave participated on which covers your issue: http://erlang.org/pipermail/erlang-questions/2011-October/thread.html#61859 Authentication failure after updating password in user document --- Key: COUCHDB-1357 URL: https://issues.apache.org/jira/browse/COUCHDB-1357 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1 Reporter: Filipe Manana Attachments: 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch From the report at the users mailing list: http://s.apache.org/9OG Seems like after updating the password in a user doc, the user is not able to login with the new password unless Couch is restarted. Sounds like a caching issue. The only case of getting the cache consistent with the _users database content is if the _users database processes crash and after the crash user documents are updated. The cache daemon is ignoring the database crash. The following patch updates the daemon to monitor the _users database and crash (letting the supervisor restart it) if the database process crashes. Etap test included. This might be related to COUCHDB-1212. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1357) Authentication failure after updating password in user document
[ https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164383#comment-13164383 ] Dave Cottlehuber commented on COUCHDB-1357: --- @pete the following might help. There are notes on raising # of FDs on both linux and windows in this thread http://erlang.org/pipermail/erlang-questions/2011-October/thread.html#61859 Try updating this in couchdb.bat assuming you're not running as a service: echo CouchDB %version% - prepare to relax... %ERL% -sasl errlog_type error -s couch +A 4 +W w -env ERL_MAX_PORTS 10 +P 100 If you're running as a service then you'll need to use erlsrv.exe http://wiki.apache.org/couchdb/Quirks_on_Windows and http://www.erlang.org/doc/man/erlsrv.html instead. There is also a short test file in http://erlang.org/pipermail/erlang-questions/2011-October/061895.html to help confirm your changes were successful. I'm not by my windows box to confirm; I'll check back later. Authentication failure after updating password in user document --- Key: COUCHDB-1357 URL: https://issues.apache.org/jira/browse/COUCHDB-1357 Project: CouchDB Issue Type: Bug Affects Versions: 1.1.1 Reporter: Filipe Manana Attachments: 0001-Let-the-credentials-cache-daemon-crash-if-_users-db-.patch From the report at the users mailing list: http://s.apache.org/9OG Seems like after updating the password in a user doc, the user is not able to login with the new password unless Couch is restarted. Sounds like a caching issue. The only case of getting the cache consistent with the _users database content is if the _users database processes crash and after the crash user documents are updated. The cache daemon is ignoring the database crash. The following patch updates the daemon to monitor the _users database and crash (letting the supervisor restart it) if the database process crashes. Etap test included. This might be related to COUCHDB-1212. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1358) Only delete files with .view extension
Only delete files with .view extension -- Key: COUCHDB-1358 URL: https://issues.apache.org/jira/browse/COUCHDB-1358 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.1.1 Reporter: Volker Mische Priority: Minor Fix For: 1.1.2 Attachments: cleanup-views-only.patch Currently all files in the view directory that are not used by any View group are deleted by the _view_cleanup endpoint. If other indexers (like GeoCouch) store indexes in the same directory, they get deleted as well. The attached patch changes the bahaviour and only deletes files ending with .view. Leftovers from compaction are deletes as well as they end with .compact.view. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1358) Only delete files with .view extension
[ https://issues.apache.org/jira/browse/COUCHDB-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Mische updated COUCHDB-1358: --- Attachment: cleanup-views-only.patch Only delete files ending with .view. Only delete files with .view extension -- Key: COUCHDB-1358 URL: https://issues.apache.org/jira/browse/COUCHDB-1358 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.1.1 Reporter: Volker Mische Priority: Minor Fix For: 1.1.2 Attachments: cleanup-views-only.patch Currently all files in the view directory that are not used by any View group are deleted by the _view_cleanup endpoint. If other indexers (like GeoCouch) store indexes in the same directory, they get deleted as well. The attached patch changes the bahaviour and only deletes files ending with .view. Leftovers from compaction are deletes as well as they end with .compact.view. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1302) Fix couchjs
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164443#comment-13164443
]
afters commented on COUCHDB-1302:
-
Not sure if it's relevant, but here's how I checked if a string is indeed an
anonymous function:
(https://github.com/afters/Couch-Incarnate/blob/master/lib/syncer.js#L38)
var verifyMapStringIsFunction = function () {
var basicFuncTemplate = new RegExp(
'^' +
'\\s*' +
'function' +
'\\s*' +
'\\(([^\\)]*)\\)' +
'\\s*' +
'{([\\s\\S]*)}' +
'\\s*' +
'$'
);
var match = basicFuncTemplate.exec(map.fn);
if (!match) throw new Error();
try {
var argsStr = match[1];
var bodyStr = match[2];
new Function(argsStr, bodyStr);
}
catch (e) {
throw new Error();
}
}
Fix couchjs
---
Key: COUCHDB-1302
URL: https://issues.apache.org/jira/browse/COUCHDB-1302
Project: CouchDB
Issue Type: Improvement
Components: JavaScript View Server
Affects Versions: 1.1.1, 1.2, 1.3
Reporter: Paul Joseph Davis
Priority: Blocker
Attachments:
0001-Prevent-linking-against-too-new-of-a-SpiderMonkey.patch,
0002-Minor-fixes-to-link-agianst-SpiderMonkey-trunk.patch
Figure out why some spidermonkeys have an error when doing:
eval(function(){})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The perfect logger for development
On Dec 7, 2011, at 4:51 AM, Benoit Chesneau wrote: On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. Hi Benoit, let's respect Jason's request when he started this thread: Seriously, please don't even mention a product or project by name. Jason, thanks for this thread. I think you're absolutely on the right track with your current wish list. Hopefully I'll find some time to write a more thorough reply later today. Cheers, Adam
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 4:11 PM, Adam Kocoloski kocol...@apache.org wrote: On Dec 7, 2011, at 4:51 AM, Benoit Chesneau wrote: On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. Hi Benoit, let's respect Jason's request when he started this thread: Seriously, please don't even mention a product or project by name. Well this mail is mixing 2 issues. So let's separate the problems. 1. managing multi transport, improving file logging (rotation), allowing the logger to handle attributes . This is a technical point and need a technical solution 2. deciding what to log, and which format. I don't really care about the second right now. It will need some time to be solved. and I'm pretty sure all expectations can't be solve easily. While the first can be solved now. And this is the more urgent imo. We indeed haven't a good solution to log actually. logging to files isn't enough, and it's not easy to change that. Abstracting the logging in fact may be indeed the first thing to do before choosing any solution. Then people can log whatever they want from any part in the code that need log. - benoît
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 5:33 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Dec 7, 2011 at 4:11 PM, Adam Kocoloski kocol...@apache.org wrote: On Dec 7, 2011, at 4:51 AM, Benoit Chesneau wrote: On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. Hi Benoit, let's respect Jason's request when he started this thread: Seriously, please don't even mention a product or project by name. Well this mail is mixing 2 issues. So let's separate the problems. 1. managing multi transport, improving file logging (rotation), allowing the logger to handle attributes . This is a technical point and need a technical solution 2. deciding what to log, and which format. I don't really care about the second right now. It will need some time to be solved. and I'm pretty sure all expectations can't be solve easily. While the first can be solved now. And this is the more urgent imo. We indeed haven't a good solution to log actually. logging to files isn't enough, and it's not easy to change that. Abstracting the logging in fact may be indeed the first thing to do before choosing any solution. Then people can log whatever they want from any part in the code that need log. - benoît Also I think we need some kind of CEP (couchdb enhancement proposal) like EEP but for couchdb to discuss about new features like this. So the people that propose that would have to do the job to be really clear, (without any mystic) and such thing. With the versionning advantage and comment on particular points. - benoît
[jira] [Commented] (COUCHDB-1358) Only delete files with .view extension
[ https://issues.apache.org/jira/browse/COUCHDB-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164630#comment-13164630 ] Paul Joseph Davis commented on COUCHDB-1358: I haven't thought about it too hard, but I've been running under the assumption that indexers would just store their files in their own directories and be responsible for their own cleanup. Is there a good reason to munge these things together? Only delete files with .view extension -- Key: COUCHDB-1358 URL: https://issues.apache.org/jira/browse/COUCHDB-1358 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.1.1 Reporter: Volker Mische Priority: Minor Fix For: 1.1.2 Attachments: cleanup-views-only.patch Currently all files in the view directory that are not used by any View group are deleted by the _view_cleanup endpoint. If other indexers (like GeoCouch) store indexes in the same directory, they get deleted as well. The attached patch changes the bahaviour and only deletes files ending with .view. Leftovers from compaction are deletes as well as they end with .compact.view. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1290) rewrite with variable and query option produces a badarg error
[
https://issues.apache.org/jira/browse/COUCHDB-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164645#comment-13164645
]
Nathan Vander Wilt commented on COUCHDB-1290:
-
Is this a dupe of [#COUCHDB-1193]?
rewrite with variable and query option produces a badarg error
--
Key: COUCHDB-1290
URL: https://issues.apache.org/jira/browse/COUCHDB-1290
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.1, 1.2
Environment: Linux geminiman 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11
UTC 2011 x86_64 GNU/Linux
Reporter: matthew o'gorman
Priority: Minor
This bug is similar or is the old bug
https://issues.apache.org/jira/browse/COUCHDB-1074
way to expose. put in rewrites.json
[ { from : foo/:blah, to : _list/foo/foo, query : {descending:
true}}]
returns
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/1
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/string
{error:unknown_error,reason:badarg}
wget http://localhost:5984/mydb/_design/mydb/_rewrite/foo/true
{error:unknown_error,reason:badarg}
it doesnt matter whats passed. removing the query from the rewrite rule and
it wont complain about badargs. tested on version 1.1 as well as
trunk-r1172741
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 08:38, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Dec 7, 2011 at 5:33 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Dec 7, 2011 at 4:11 PM, Adam Kocoloski kocol...@apache.org wrote: On Dec 7, 2011, at 4:51 AM, Benoit Chesneau wrote: On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. Hi Benoit, let's respect Jason's request when he started this thread: Seriously, please don't even mention a product or project by name. I'm on board with this. Let's just whiteboard a little more. I pretty much agree with everything specified so far. One point I would add (I didn't see it) is that it should be possible to wholesale swap out the logging system with a compatible one via a config change. That's kind of in line with my thinking about couchdb in general these days. Also I think we need some kind of CEP (couchdb enhancement proposal) like EEP but for couchdb to discuss about new features like this. So the people that propose that would have to do the job to be really clear, (without any mystic) and such thing. With the versionning advantage and comment on particular points. That could be interesting. Want to start a thread about it? I think this ties in nicely with the momentum around documentation improvements. -Randall
Re: The perfect logger for development
On Wed, Dec 7, 2011 at 12:52, Randall Leeds randall.le...@gmail.com wrote: On Wed, Dec 7, 2011 at 08:38, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Dec 7, 2011 at 5:33 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Wed, Dec 7, 2011 at 4:11 PM, Adam Kocoloski kocol...@apache.org wrote: On Dec 7, 2011, at 4:51 AM, Benoit Chesneau wrote: On Wed, Dec 7, 2011 at 10:38 AM, Jason Smith j...@iriscouch.com wrote: Thanks, Benoit. I would like to move the discussion back, one hundred percent, to identifying exactly what features are good and bad for CouchDB. We are in no hurry. IMHO, CouchDB does not need a patch soon. It needs thoughtful, deliberate planning. yes and no . We don't need to be 100% to start implementation. For example we could just replace our current logger by lagger which would give us automatically support for different backend, log rotations co and prepare for more attributes as well. Hi Benoit, let's respect Jason's request when he started this thread: Seriously, please don't even mention a product or project by name. I'm on board with this. Let's just whiteboard a little more. I pretty much agree with everything specified so far. One point I would add (I didn't see it) is that it should be possible to wholesale swap out the logging system with a compatible one via a config change. That's kind of in line with my thinking about couchdb in general these days. That may actually be an unreasonable request and I'm not sure exactly what I meant by it. Also I think we need some kind of CEP (couchdb enhancement proposal) like EEP but for couchdb to discuss about new features like this. So the people that propose that would have to do the job to be really clear, (without any mystic) and such thing. With the versionning advantage and comment on particular points. That could be interesting. Want to start a thread about it? I think this ties in nicely with the momentum around documentation improvements. -Randall
