modular or monolithic: how do you envision Apache CouchDB?
Hi, Last day we had a quick discussion on IRC about splitting code in different apps or not. I wasn't totally crystal clear about my position and I would like to clarify it a little. Imo everything turn around the question , "how do you envision Apache CouchDB". It appears for me that some wants to distribute it as a full product, everything is embedded in one archive. In that case the distributiuon system is only targeting this goal and nothing in the core allows alternatives. While I'm agree we should offer a "canonical" release of Apache CouchDB, I'm thinking more Apache CouchDB as a collections of modules with a core. For example CouchDB could be: a k/v server that can live on one or more machine : the core with an HTTP api with a M/R api also accessible with HTT with a _changes API with a replicaton API with a couchapp engine with javascript support So anyone can eventually replace, remove or add a module in its own couchdb distribution. The release system could also be enough smart to allws a distributor to customize its own couchdb. What do you think about it? How do you envision CouchDB ? - benoîr
Re: Git Push Summary
The Git history is source code too. Reading and comprehending is key. We spend as much or more time reading Git logs as building new ones. FWIW (not much) I would prefer a few minutes grace period where people can push --force, rather than a tangled git history conveying no information except that somebody made an error. On Sun, Feb 5, 2012 at 10:05 AM, Paul Davis wrote: > Noah managed to merge 1.2.x to itself. I caught it in a few minutes so > made a snap decision and fixed it. I plan on fixing up the hooks > tomorrow to prevent it from happening again. > > On Sun, Feb 5, 2012 at 3:00 AM, Paul Davis > wrote: >> This is not the commit you are looking for. >> >> On Sun, Feb 5, 2012 at 1:32 AM, Randall Leeds >> wrote: >>> What happened here? Why forced? >>> >>> On Fri, Feb 3, 2012 at 14:04, wrote: Updated Branches: refs/heads/1.2.x 05a6aea97 -> 506deab47 (forced update) -- Iris Couch
Re: Git Push Summary
Noah managed to merge 1.2.x to itself. I caught it in a few minutes so made a snap decision and fixed it. I plan on fixing up the hooks tomorrow to prevent it from happening again. On Sun, Feb 5, 2012 at 3:00 AM, Paul Davis wrote: > This is not the commit you are looking for. > > On Sun, Feb 5, 2012 at 1:32 AM, Randall Leeds wrote: >> What happened here? Why forced? >> >> On Fri, Feb 3, 2012 at 14:04, wrote: >>> Updated Branches: >>> refs/heads/1.2.x 05a6aea97 -> 506deab47 (forced update)
Re: Git Push Summary
This is not the commit you are looking for. On Sun, Feb 5, 2012 at 1:32 AM, Randall Leeds wrote: > What happened here? Why forced? > > On Fri, Feb 3, 2012 at 14:04, wrote: >> Updated Branches: >> refs/heads/1.2.x 05a6aea97 -> 506deab47 (forced update)
Re: Git Push Summary
What happened here? Why forced? On Fri, Feb 3, 2012 at 14:04, wrote: > Updated Branches: > refs/heads/1.2.x 05a6aea97 -> 506deab47 (forced update)
Re: backport of couchdb
I haven't tried to build the debian .deb yet, but it should build from my branch at github[1]. I used git-dpm for the packaging. It should be enough to check out that branch and pbuild it or whatever preferred tools you use. The Ubuntu version is uploaded to a PPA [2]. If there's interest I'll roll a binary or source .deb on a debian chroot. Someone got to tell me which debian release I should use though (or several?). I'll also try to pull together a 1.2 package for the latest Ubuntu LTS release. I guess I should probably do debian stable and testing (but not unstable?) [1] http://github.com/tilgovi/couchdb/tree/debian [2] https://launchpad.net/~randall-leeds/+archive/couchdb/ On Sat, Feb 4, 2012 at 10:24, till wrote: > I remember Randall had a launchpad repo to build CouchDB. (CC'd him, maybe > he can weigh in how far he got) > > Launchpad is probably not a 100% compatible with Debian (since it targets > Ubuntu distributions) but the 'basic formula' could be contributed to > something like dotdeb? > > Anyone have thoughts? > > Till > > On Fri, Feb 3, 2012 at 11:42 AM, Jens Rantil wrote: >> >> Hi again everyone, >> >> I am happy to get a discussion going about this. I'd say Debian is a major >> platform for servers. Therefor, I believe CouchDB should exist there - with >> a reasonable modern version. Sure, you can install from source. However, >> with CouchDB and it's replication features it should be easy to roll it out >> to a multitude of Debian servers and kick off replication. >> >> Also, previously Couchbase was hosting a (sadly, buggy) Debian package. >> After the death of the Couchbase package[1] there is no modern Debian >> package alternative anymore. >> >> To keep this discussion going - what did you think of Jan's proposal to >> set up a Debian maintainer mailing list? As of the initial question, shall >> Debian stable installations be living with 0.11 for another ~6 months? I >> guess so. >> >> /J >> >> -Ursprungligt meddelande- >> Från: Jan Lehnardt [mailto:j...@apache.org] >> Skickat: den 31 januari 2012 21:42 >> Till: dev@couchdb.apache.org >> Kopia: Laszlo Boszormenyi >> Ämne: Re: backport of couchdb >> >> Hi Laszlo, >> >> On Jan 31, 2012, at 21:24 , Laszlo Boszormenyi wrote: >> >> > Hi, >> > >> > First, I'm an official DD and the maintainer of CouchDB. >> >> Pleased to meet you and thanks for weighing in on this discussion :) >> >> >> >> As for the back porting, Debian doesn't directly manage any packages. >> >> Everything has a package maintainer who may or may not be part of the >> >> Debian staff, so it really does land on the maintainer. And I don't >> >> see how you could back port fixes from, say, 1.x.x to 0.x.x. >> > Let me ask an other way. Is CouchDB expected to change a lot >> > internally? >> >> I think it is. The question, I think, is how much end-users will be >> affected by these changes (upgrade trouble, incompatibilities etc.) We are >> doing our best to not break BC (according to semver.org) and make upgrades >> seamless and well documented. >> >> > What about helping downstream with security fixes? >> >> We could start a new mailing list package-maintain...@couchdb.apache.org >> where downstream folks can subscribe and get notified about impeding >> releases as well as security notices. Would that be a good first step? >> What else could we do to help you downstream? >> >> > When CouchDB 1.2.0 is expected to be released? >> >> We are expecting to call a vote in the next few days (pending release >> manager time). As per our process, it'll take 4-5 days after the initial >> call for voting to get the release out (if the votes don't go through and if >> issues are found, this process is reset). >> >> Let us know if you have any other questions and thanks again for helping >> out! >> >> Cheers >> Jan >> -- >> >
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200525#comment-13200525
]
Alexander Shorin commented on COUCHDB-1397:
---
[offtopic]
Sorry for offtopic, but
@Marcello,
Why not to use black box testing instead of trying to mock every internal query
server global function? Using QS directly as black box you will have warranty
that your functions are tested well, because box is real, but you don't have to
know how it works. In your way you testing for your own, may miss some details
and output result could be different. This is not only about views that are not
so complex as show or list functions. By the way, applying your idea to other
functions I'll something weird for list function:
function(head, req, provides, registerType, getRow, send, start,
whatEverWillBeAddedInFuture){
...
}
Looks not much relaxing(: Certainly, Javascript allows to skip some function
arguments definition, but it still requires(?) them in right order.
And what about other query servers in this case? Currently, they are doing same
work as Javascript one or just trying to do, but not all of them could skip
arguments definition, has arguments vectors etc. This could create additional
problems with migration from one QS to another.
[/offtopic]
About subject, I couldn't say anything important about function(...){} vs
function name(...){} vs ... because I don't use Javascript query server, but in
Python I have to write real functions with their names - it works as nice
marker to find their crush in debug logs if it happens, so for me this is just
nice feature(:
P.S. Just a moment, what will happens with CoffeeScript in case of proposed
changes?
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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: backport of couchdb
I remember Randall had a launchpad repo to build CouchDB. (CC'd him, maybe he can weigh in how far he got) Launchpad is probably not a 100% compatible with Debian (since it targets Ubuntu distributions) but the 'basic formula' could be contributed to something like dotdeb? Anyone have thoughts? Till On Fri, Feb 3, 2012 at 11:42 AM, Jens Rantil wrote: > Hi again everyone, > > I am happy to get a discussion going about this. I'd say Debian is a major > platform for servers. Therefor, I believe CouchDB should exist there - with > a reasonable modern version. Sure, you can install from source. However, > with CouchDB and it's replication features it should be easy to roll it out > to a multitude of Debian servers and kick off replication. > > Also, previously Couchbase was hosting a (sadly, buggy) Debian package. > After the death of the Couchbase package[1] there is no modern Debian > package alternative anymore. > > To keep this discussion going - what did you think of Jan's proposal to > set up a Debian maintainer mailing list? As of the initial question, shall > Debian stable installations be living with 0.11 for another ~6 months? I > guess so. > > /J > > -Ursprungligt meddelande- > Från: Jan Lehnardt [mailto:j...@apache.org] > Skickat: den 31 januari 2012 21:42 > Till: dev@couchdb.apache.org > Kopia: Laszlo Boszormenyi > Ämne: Re: backport of couchdb > > Hi Laszlo, > > On Jan 31, 2012, at 21:24 , Laszlo Boszormenyi wrote: > > > Hi, > > > > First, I'm an official DD and the maintainer of CouchDB. > > Pleased to meet you and thanks for weighing in on this discussion :) > > > >> As for the back porting, Debian doesn't directly manage any packages. > >> Everything has a package maintainer who may or may not be part of the > >> Debian staff, so it really does land on the maintainer. And I don't > >> see how you could back port fixes from, say, 1.x.x to 0.x.x. > > Let me ask an other way. Is CouchDB expected to change a lot > > internally? > > I think it is. The question, I think, is how much end-users will be > affected by these changes (upgrade trouble, incompatibilities etc.) We are > doing our best to not break BC (according to semver.org) and make > upgrades seamless and well documented. > > > What about helping downstream with security fixes? > > We could start a new mailing list package-maintain...@couchdb.apache.org > where downstream folks can subscribe and get notified about impeding > releases as well as security notices. Would that be a good first step? > What else could we do to help you downstream? > > > When CouchDB 1.2.0 is expected to be released? > > We are expecting to call a vote in the next few days (pending release > manager time). As per our process, it'll take 4-5 days after the initial > call for voting to get the release out (if the votes don't go through and > if issues are found, this process is reset). > > Let us know if you have any other questions and thanks again for helping > out! > > Cheers > Jan > -- > >
[jira] [Commented] (COUCHDB-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200471#comment-13200471
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
CommonJS is fine, but it doesn't help for unit testing. CommonJS is a linker
(runs on load time), dependency injection is done at run-time. One assembles
code, the other object graph. Not the same thing.
To ease unit testing, you need dependency injection. You can't easily test:
function (doc) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
emit(doc._id, 1);
}
}
It's doable (I'm doing it), but not easy. Testing the following is trivial:
function (doc, view, require) {
var util = require('views/lib/util');
if (util.isSomething(doc)) {
view.emit(doc._id, 1);
}
}
Globals, make the code harder to:
- read (where do these values come from?);
- test (how do I mock globals at run-time?);
- write (you need to tell to your code-checker what globals you use.)
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-249) Treat output rows of views as documents for other views to build upon
[
https://issues.apache.org/jira/browse/COUCHDB-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200441#comment-13200441
]
Christoph Zrenner commented on COUCHDB-249:
---
Hi all, I've been using CouchDB for about 6 months now (an amazing technology)
and we implemented a "prediction engine" using a bayesian classifier inside a
view. The parameters for the machine learning algorithm is in a commonjs array
and every 24 hours we modify the parameters based on updates from the manual
verified training data added that day (like in spam/ham classification), so
then the view is rebuilt. It seems like this might be a use case that would be
well served with chained views, so I'm adding it here to this ticket:
So after the predictions are calculated, there are then a bunch of further
analytics calculation that happen based on the predicted data, but the
predictions are only temporary (the prediction parameters are updated every
24h). Right now, I'm doing the same bayes prediction calculation in each of the
analytics views (inside a commonjs function "BayesPredictor") but this means
that the same calculations are performed for each analytics view.
Chaining the temporary and computationally intense prediction calculation
output with a subsequent analysis view "feels" like it might be a good solution
for this problem. I'm reluctant to write the predictions into another database
as in the cloudant solution, if I was to go that route, then I think I may as
well just keep updating my source documents by going through all_documents and
updating the predictions on each document every 24h.
Would very much appreciate any views on whether this is a "valid" use-case for
native chained views and any advice on how I might implement this! Thanks.
> Treat output rows of views as documents for other views to build upon
> -
>
> Key: COUCHDB-249
> URL: https://issues.apache.org/jira/browse/COUCHDB-249
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core, Infrastructure, JavaScript View Server
>Reporter: Joey Lawrance
> Attachments: couch_view_updaer.erl.patch.txt, couch_view_updater.erl
>
>
> Unless I manually copy the JSON rows of a view into a new document, I am
> unable to create new views that are computed from existing views. That is, it
> seems as if views are second class citizens compared to first-class documents.
> Suppose I wanted to find the spread between the cheapest suppliers and the
> most expensive suppliers of each fruit. I know it's possible to use one
> map/reduce to compute such a view, but I'd like to be able to re-use my
> existing "cheapest" and "costliest" views. That is, I'd like to use the
> document output of these views as input into another view.
> I started with the simple fruit store example in the CouchDB book. I
> developed a simple view called "cheapest" with the following map and reduce
> functions (the "costliest" view is the same as "cheapest" but except the
> reduce function's comparison is the other way around):
> function(doc) {
> var store, price, key;
> if (doc.item && doc.prices) {
> for (store in doc.prices) {
> price = doc.prices[store];
> key = doc.item;
> emit(key, {store:store, price:price});
> }
> }
> }
> function(item,store) {
> var m = store[0];
> for (i in store) {
> if (m.price > store[i].price) m = store[i];
> }
> return m;
> }
> The output is as follows:
> {"rows":[
> {"key":"apple","value":{"store":"Apples Express","price":0.79}},
> {"key":"banana","value":{"store":"Price Max","price":079}},
> {"key":"orange","value":{"store":"Citrus Circus","price":1.09}}
> ]}
> I'd like to develop a new view whose input is the output of the view above,
> but as far as I can tell, views only operate on documents, not the output of
> existing views. Am I missing something?
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200387#comment-13200387
]
Jason Smith commented on COUCHDB-1397:
--
@Marcello, yes I am okay with the idea of JavaScript programs (I've realized
the word "invalid" is not helpful in this discussion).
However once again, CommonJS is the clear, obvious goal. It clarifies and
unifies CouchDB, and CouchApps would immediately become Node.js apps (at least,
you could require() their parts for unit testing which I have started to do as
well.)
I agree that emit(), log(), etc. should be global; but I disagree that they can
be injected. There is a third way, the way CommonJS works. The code is
implicitly wrapped in a larger function where `emit`, `log`, etc. had been
passed as parameters.
In CommonJS, your code is inside a function--not even conceptually, really. See
share/server/util.js, around line 90.
var s = "function (module, exports, require) { " + newModule.current + " }";
This is the sort of source code transforms I hope Paul would agree is fine. If
newModule.current was wrong before (suppose it defined an anonymous function),
then it is still wrong. And this pattern is well-known and well-exercised in
several JavaScript environments. Perhaps one day there will be:
var map_runner = "function (emit, log, sum) { " + map_value + "}"
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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-1397) Function expressions, evals in SpiderMonkey
[
https://issues.apache.org/jira/browse/COUCHDB-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200384#comment-13200384
]
Marcello Nuccio commented on COUCHDB-1397:
--
@Jason,
I've found that, using valid Javascript in map/reduce, eases development for
me, because I can use standard tools (uglifyjs, jshint, ...) without extra work.
Moreover, I would also remove all global functions and inject them:
function sampleMap(doc, view) {
view.emit(doc._id, null);
}
because this makes unit testing much more easier than now.
Ease of development and ease of testing it's much more relaxing for me, than
the possibility to use anonymous functions.
> Function expressions, evals in SpiderMonkey
> ---
>
> Key: COUCHDB-1397
> URL: https://issues.apache.org/jira/browse/COUCHDB-1397
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
>Affects Versions: 1.2.1
> Environment: All
>Reporter: Jason Smith
>
> New SpiderMonkey releases do not eval() a sole anonymous function expression.
> That is not a valid JavaScript statement, and so it is not a valid JavaScript
> script.
> COUCHDB-1302 addressed this for 1.1 and the 1.1.x branch. This ticket is for
> 1.2. (Sorry to spam COUCHDB-1302. I saw "Unassigned" and read "Unresolved.")
--
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
