[jira] [Created] (COUCHDB-1499) CouchDB daemon terminates when the computer goes to sleep
Ivan Krechetov created COUCHDB-1499: --- Summary: CouchDB daemon terminates when the computer goes to sleep Key: COUCHDB-1499 URL: https://issues.apache.org/jira/browse/COUCHDB-1499 Project: CouchDB Issue Type: Bug Components: Infrastructure Affects Versions: 1.2, 1.1.1 Environment: OS X 10.6.8 Reporter: Ivan Krechetov Priority: Minor Log entries on sleep and wake up: heart: Mon Jun 18 18:28:11 2012: heart-beat time-out. heart: Mon Jun 18 20:52:23 2012: Executed "/usr/local/Cellar/couchdb/1.2.0/bin/couchdb -k". Terminating. heart_beat_kill_pid = 62249 heart_beat_timeout = 11 Then, I just start it manually again, after the OS wakes up: Apache CouchDB 1.2.0 (LogLevel=info) is starting. Apache CouchDB has started. Time to relax. [info] [<0.31.0>] Apache CouchDB has started on http://127.0.0.1:5984/ -- 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-1498) range_prefix view parameter to ease working with ranges
[ https://issues.apache.org/jira/browse/COUCHDB-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395988#comment-13395988 ] Ronny Pfannschmidt commented on COUCHDB-1498: - the main issue is - that from what i gathered - all wrong key prefixes are used out there, to supposedly mean what i want to archieve i suppose its reasonable to assume to do this only for one level of nesting (only work for string key and array key, don’t consider partial of the last item( i still would like to propose both variants, keyprefix would be strict, and consider only items in the toplevel sequence (so it would work for strings and arrays and solve most simple cases) rangeprefix would recurse on the last item of the sequence if it is a array or string but im under the impression that the rangeprefix idea is a bit too complicated and may cause grief in the long run > range_prefix view parameter to ease working with ranges > --- > > Key: COUCHDB-1498 > URL: https://issues.apache.org/jira/browse/COUCHDB-1498 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: Ronny Pfannschmidt > > queries for certain ranges are a common operation, > but we are usually left with figuring what kind of start/end key combination > to use if we want a certain range > it would be really pleasant if instead of constructing a start/end range from > a prefix by guessing mostly how to construct the end param, > we could just pass the range prefix as a string/array to the 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-1498) range_prefix view parameter to ease working with ranges
[
https://issues.apache.org/jira/browse/COUCHDB-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395969#comment-13395969
]
Robert Newson commented on COUCHDB-1498:
Those are the kinds of thing I thought you meant and, for me, they fail my
point 1 in that the values chosen for startkey/endkey will depend on the types
of the supplied range_prefix value. This is surprising and potentially very
confusing.
I'll note, since you raised them, that none of the startkey/endkey examples are
quite right.
Futon find design documents using startkey="_design/"&endkey="_design0" since
design documents, by definition, occupy a namespace delimited by / and 0 is the
next character up from there.
The assumption that empty object is the intended endkey in your second example
is questionable and the assumption that Z is the last letter of the alphabet is
false.
I'd like to hear from other developers but I don't in general see a solid
heuristic for guessing correct startkey and endkey values from a prefix value.
While it seems intuitive in the cases Ronny mentions, the devil, as always, is
in the details.
To end on a more positive note, I would suggest this as the least surprising,
but still useful enhancement;
?keyprefix=["foo"]
This will *only* work for array keys and will not guess partially completed
items. The above query will find ["foo"], ["foo", 12], ["foo", {"foo":"bar"}],
["foo", bar"], etc (but not ["goo"], or ["food"]).
> range_prefix view parameter to ease working with ranges
> ---
>
> Key: COUCHDB-1498
> URL: https://issues.apache.org/jira/browse/COUCHDB-1498
> Project: CouchDB
> Issue Type: Bug
> Components: View Server Support
>Reporter: Ronny Pfannschmidt
>
> queries for certain ranges are a common operation,
> but we are usually left with figuring what kind of start/end key combination
> to use if we want a certain range
> it would be really pleasant if instead of constructing a start/end range from
> a prefix by guessing mostly how to construct the end param,
> we could just pass the range prefix as a string/array to the 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-1498) range_prefix view parameter to ease working with ranges
[
https://issues.apache.org/jira/browse/COUCHDB-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395941#comment-13395941
]
Ronny Pfannschmidt commented on COUCHDB-1498:
-
a first example would be finding ddocs
current way startkey="_design/" endkey= "_desigm" or "design/\u"
rage way would be range_prefix="design/"
another examples would be something like get articles of a month/year
current way startkey=[year, month] endkey=[year, month, {}]
range way would be range_prefix=[year, month]
last example would be multiple string parts
if one had with various values foremit(['something', 'another'], null)
and would like to get anything that "starts with" ["something", "anot"]
current way startkey=["something", "anot"], endkey=["something", "anotZZZ"]
range way would be range_prefix=["something", "anot"]
as a sidenote, it seems that this kind of prefix handling makes only sense for
strings, arrays, and last strings of an array
> range_prefix view parameter to ease working with ranges
> ---
>
> Key: COUCHDB-1498
> URL: https://issues.apache.org/jira/browse/COUCHDB-1498
> Project: CouchDB
> Issue Type: Bug
> Components: View Server Support
>Reporter: Ronny Pfannschmidt
>
> queries for certain ranges are a common operation,
> but we are usually left with figuring what kind of start/end key combination
> to use if we want a certain range
> it would be really pleasant if instead of constructing a start/end range from
> a prefix by guessing mostly how to construct the end param,
> we could just pass the range prefix as a string/array to the 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-1498) range_prefix view parameter to ease working with ranges
[ https://issues.apache.org/jira/browse/COUCHDB-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13395895#comment-13395895 ] Robert Newson commented on COUCHDB-1498: Included to close as 'won't fix' but I'll give it more time to see if someone can justify this addition. If you don't know the range you want then I don't see how 'range_prefix' can help, and if you do know the range you want, you by definition know the startkey and endkey values. Provide some examples of this new API that would improve usability without a) potentially being the wrong answer and b) being easier to figure out that startkey/endkey. > range_prefix view parameter to ease working with ranges > --- > > Key: COUCHDB-1498 > URL: https://issues.apache.org/jira/browse/COUCHDB-1498 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: Ronny Pfannschmidt > > queries for certain ranges are a common operation, > but we are usually left with figuring what kind of start/end key combination > to use if we want a certain range > it would be really pleasant if instead of constructing a start/end range from > a prefix by guessing mostly how to construct the end param, > we could just pass the range prefix as a string/array to the 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] [Created] (COUCHDB-1498) range_prefix view parameter to ease working with ranges
Ronny Pfannschmidt created COUCHDB-1498: --- Summary: range_prefix view parameter to ease working with ranges Key: COUCHDB-1498 URL: https://issues.apache.org/jira/browse/COUCHDB-1498 Project: CouchDB Issue Type: Bug Components: View Server Support Reporter: Ronny Pfannschmidt queries for certain ranges are a common operation, but we are usually left with figuring what kind of start/end key combination to use if we want a certain range it would be really pleasant if instead of constructing a start/end range from a prefix by guessing mostly how to construct the end param, we could just pass the range prefix as a string/array to the 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
Re: couchdb osx binary branding
Hi Benoit, 1) I agree. I missed the "CouchDB Server" Title. Menu items are ok though. I will refactor the title in the next version. 2) I don't see a problem here. The codebase was initially created by Jan and he chose the Apache License 2.0. That License is still intact, independent from where the source code is located. Anyway there are a lot of components that are not in the "official" repo like curl, otp, icu, spidermokey, etc. I mean we all know that CouchDB has a lot of components. The OS X app wrapper is just a small addition. Your argument about source locations, copyrights and being "official" is also valid for the Windows build. It contains all these components not in the official repo. 3) Agreed about the ABOUT. I will add a link. - Hans On Jun 18, 2012, at 10:06 AM, Benoit Chesneau wrote: > hi, > > I have some problems with the current binary linked on the homepage. > Not with the binary by itself which works but with the branding. > > 1. Titte in about is "CouchDB Server" I don't know what it's means. If > linked on the homepage, it should be "Apache CouchDB" imo and nothing > else. Other than that we should just link it on the wiki. > 2. Copyright. imo we should only have the apache copyright for > anything "official". How these copyrights will work if we include the > osx build in the sources btw ? > 3. Since the source code isn't in the apache couchdb repository, a > link to the OSX sources should be provided in the ABOUT. It's not > required by the aoache 2 license, but generally we expect to find the > sources in the repository when it comes from an apache project? > > Anyway both can be fixed when the sources will be included in the repo > (Is the process started) ? > > Awaiting that I would like to see something that tag the binary as non > official or supported on the homepage. > > - benoit
Re: git commit: Automate maintenance of the THANKS file
Speaking of that, can I ask to add me to THANKS file? ;) Cheers, Fedor. On Mon, Jun 18, 2012 at 12:09 AM, Jan Lehnardt wrote: > > On Jun 17, 2012, at 22:05 , Paul Davis wrote: > > > On Sun, Jun 17, 2012 at 3:02 PM, Jan Lehnardt wrote: > >> > >> On Jun 17, 2012, at 21:56 , Paul Davis wrote: > >> > >>> On Sun, Jun 17, 2012 at 2:44 PM, Jan Lehnardt wrote: > > On Jun 17, 2012, at 21:29 , Paul Davis wrote: > > > I'm not sure I like this so much. Playing around with it, its a bit > > prone to screw ups. > > I just don't want to maintain this file manually any more. It is > error-prone and makes merging user-contributions a pain. I'm happy > to have this implemented in any other way, but I think we should > try to remove any mechanical steps from maintaining our source if > we can. I hope you agree! :) > > >>> > >>> Its an extra step but not one that I find to be particularly onerous. > >>> Given that we're already working on codifying merge practices I don't > >>> see why we don't just add a check box for "includes commit adding > >>> yourself to the THANKS file if this is your first contribution" that > >>> we look for. > >> > >> That's a fair point, but this has annoyed me forever. > >> > > It also breaks if AUTHORS.gz exists before you > > pull in new commits. We could solve that by forcing it to build every > > time but that's a bit of a hack for not much gain. > > Can you explain how it breaks if AUTHORS.gz exists before the merge? > If you mean THANKS.gz, my idea was that this is only relevant on > packaging time (make distcheck) where THANKS.gz by definition does > not exist. > > >>> > >>> I'm not sure its a good idea to have a file that is only built > >>> correctly in special circumstances. > >> > >> I'm happy to add an rm -f $< to the target. > >> > >> > > Its also got Benoit in there twice since he made commits with > slightly > > different author/committer names which also seems awkward. > > The subsequent .mailmap commit fixes the dupes. The push emails seem > to be delayed atm, I reported this to danielsh on #asfinfra. > > >>> > >>> I'm confused. You've removed one manually curated file only to add a > >>> new one that just modifies the build of the first? Seems like a lot of > >>> gymnastics. > >> > >> .mailmap solves more than just this. > >> > >> > >>> In a perfect world I would be all in with you on this but > >>> unfortunately a large number of people don't spend time checking their > >>> user settings before pushing commits around. Instead of just adding > >>> people to a file the first time they make a commit this means I have > >>> to go and check that the THANKS file is generated properly and then > >>> maybe update .mailmap if not and recheck that I got it correct. > >> > >> Fair enough, wanna revert? > >> > >> Cheers > >> Jan > >> -- > >> > >> > > > > Playing with it a bit to see if I can make it build correctly and also > > just build the AUTHORS file. I'll leave it around for a bit but won't > > promise that the first time I spend more than 30s screwing with > > mailmap that I revert it. > > Heh, that took me a while to get right :) > > Cheers > Jan > -- > > >
Re: [PROPOSAL] Official roadmap, and merge procedure
On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater wrote: > Devs, > > A few of us met in Dublin recently, and we discussed the project roadmap. > > Key takeaways from that meeting: > > 1. We'd like to proposed formal time-based releases > > > 2. Branch and hack all you like, but if you want to ship something, you > have to submit a merge request to an active release branch. Before you do > this, you should follow a test procedure. And before your request will be > accepted, it will be put through QA by the community. > > > Details of these proposals can be found here: > > http://wiki.apache.org/couchdb/Roadmap_Process > > > http://wiki.apache.org/couchdb/Merge_Procedure > > > Please reply back to this thread with your comments on the proposals. > > (The last one needs to be fleshed out, a little...) > > Thanks, > > N Thanks for these wikis. Roadmap process is good but the merge procedure is a little obscure. *) What happen in master during the release procedure? Are you freezing it ? Imo we should freeze it except if we want to reedit the current nightmare. Freezing the master give the following advantage: - focus developers on the release - make sure anything done for the release will be easily merged in the master. Imo this freeze shouldn't be a problem since we have the topic/features branches to continue devs on other things. or remote branch. Anyway this should be clear on the wiki. *) You're speaking about merge, but what if a bugfix only goes for a release and doesn't apply to master and other releases branches? I'm thinking to 2 scenari there: - bug only happen in a release branch and has only be raised here. Where should the bugfix should be applied first? Do we care to try to merge it in other branches (painful and open the door to other bugs) - bug is found in the master: what is the procedure to check if this bu g apply to other branch *) related to above: release manager: whos is (s)he ? Only one guy? Do we have like in perl or debian a release manager / major versions ? Having one release manager / version would do the trick, since he would be supposed to know the state of the last version of his release (1.x, 2.x) ... And how bugs can be applied in. Anyway hope we can answer to these questions. - benoît
couchdb osx binary branding
hi, I have some problems with the current binary linked on the homepage. Not with the binary by itself which works but with the branding. 1. Titte in about is "CouchDB Server" I don't know what it's means. If linked on the homepage, it should be "Apache CouchDB" imo and nothing else. Other than that we should just link it on the wiki. 2. Copyright. imo we should only have the apache copyright for anything "official". How these copyrights will work if we include the osx build in the sources btw ? 3. Since the source code isn't in the apache couchdb repository, a link to the OSX sources should be provided in the ABOUT. It's not required by the aoache 2 license, but generally we expect to find the sources in the repository when it comes from an apache project? Anyway both can be fixed when the sources will be included in the repo (Is the process started) ? Awaiting that I would like to see something that tag the binary as non official or supported on the homepage. - benoit
