Closed nmalkin closed 12 years ago
In the time it took me to write this out, I've realized that while the code will be duplicated across views, the code for setting up those views can be shared. The map
s will be different, but the reduce
should be the same, even across different reports.
Though the underlying issue remains, it's not as big a deal as I originally thought. (The reused code is in the database, not the codebase.)
I'm therefore closing this issue right away (but creating it first, in case we want to bring back this discussion.)
For background, and what we're trying to accomplish, please see #27.
(Example) task
Counting the number of step completions in a given date range
To get this data, we set up a view in CouchDB:
Then, for example, if we wanted a report for June, we could query the view with
startkey=2012-06-01&endkey=2012-16-30&group=false
. Easy enough.More complicated
Same task, but now we want to see the data segmented by operating system. So we set up a view.
A little bit more complicated, but overall pretty similar. Quite manageable.
Problems
Okay, that worked, but now we want to segment by browser. That's very similar. The only difference is that, instead of using the doc.os field, we'd need to use the doc.browser field.
Here's the problem: because views in CouchDB can't take arbitrary parameters, we'd have to create a completely separate view with nearly identical code.
And then again, when we want to segment by screen size. And for locale, and so on.
For each segmentation (there will be at least 5 of them), a new view will have to be created, and it will be nearly identical to the other ones.
Furthermore, since most reports will have segmentations, the views will be duplicated across reports.
Question
How can we avoid this?