On Apr 28, 2009, at 11:42 AM, Brian Candler wrote:
On Sun, Apr 26, 2009 at 11:26:33PM +0200, Wout Mertens wrote:
In a nutshell, I'm hoping that:
* A review is a new sort of view that has an inputs array in its
definition.
* Only MR views are allowed as inputs, no KV duplication allowed.
* It
On Apr 28, 2009, at 8:13 AM, Wout Mertens wrote:
On Apr 28, 2009, at 11:42 AM, Brian Candler wrote:
Furthermore, if I understand rightly, these grouped reduce values
are *not*
persisted anywhere (*). That is: every time you do a
reduce=truegroup=true
query then the entire map index is
@jchris et al,
if you had any pointer, on how to implement this, i have a strong
motivation to try my hand at it.
i have a janky ruby script running as an update notifier that looks
for certain criteria, idiomatic to my data, that puts docs into a
derived database. but i'm not terribly happy
Zachary,
Awesome. The thing with non-incremental updates is that the basic
algorithm would be to just look for updates to the view and on update,
delete the review DB, create a new one, and then dump the new data into
it. I wouldn't try too hard for the optimizing updates at this point in
paul
alright... you've gotta give me the remedial explanation of what you
meant here! (sorry, i'm still noob-ish)
so, are you saying that i shouldn't even check for individual doc
updates, but instead just recreate the entire database? that sounds
like a job for cron, more so than the update
okay, i'm starting to get ya. my question is, if i'm constantly
dropping/recreating/reindexing the derived database, how can i keep
serving requests from my website?
one possible solution would be to time/etag/etc-stamp the derived db
name, but that would seem to add a number of moving parts to
Perhaps the background job could maintain some versioning number, in
the base DB's design doc, which clients could use to know which
version of the derived database to hit.
See? ;^) This might be simpler, as a 1st-class CouchDB feature, than a
bolted-on script.
On Mon, Apr 27, 2009 at 2:48 PM,
On Apr 23, 2009, at 2:52 AM, Paul Davis wrote:
I'm still kicking around ideas on how I might approach such an
implementation. There are some obvious downfalls that Wout has come up
on. Specifically, some obvious implementations would place some
arduous constraints on emitted keys (namely:
Hi Adam,
On Apr 22, 2009, at 4:48 PM, Adam Kocoloski wrote:
Hi Wout, thanks for writing this up.
One comment about the map-only views: I think you'll find that
Couch has already done a good bit of the work needed to support
them, too. Couch maintains a btree for each design doc keyed on
I would definitely +1 something like this.
I'm essentially do something like this manually, with an update
notifier script, and I'd love to see it become a first-class feature
—instead of my special-case version of it.
On Wed, Apr 22, 2009 at 7:40 AM, Wout Mertens wout.mert...@gmail.com wrote:
This also sounds related to the View Intersections proposal
discussed earlier...
http://mail-archives.apache.org/mod_mbox/couchdb-dev/200904.mbox/%3c011a0d62-06c2-490b-a4c4-7eef0203b...@gmail.com%3e
On Wed, Apr 22, 2009 at 9:07 AM, Zachary Zolton
zachary.zol...@gmail.com wrote:
I would
Hi Wout, thanks for writing this up.
One comment about the map-only views: I think you'll find that Couch
has already done a good bit of the work needed to support them, too.
Couch maintains a btree for each design doc keyed on docid that stores
all the view keys emitted by the maps over
12 matches
Mail list logo
