On Nov 3, 2008, at 10:35, Ask Bjørn Hansen wrote:
On Nov 2, 2008, at 14:28, Paul Davis wrote:
There are two main thoughts at the moment. Group views like you have
by data that is indexed, or group everything required for a given
application in a single design doc.
Interesting - thanks!
Another thought I had was that index updates on big databases really
need to be transactional in a way.
I was thinking of having my application do some indirection to find
the design document / view name; so rather than just doing GET /foo/
_view/foo/bar then do GET /foo/view_foo which would return something
like { "current": "foo234", "next": "foo235" }
A similar suggestion has been brought up on the -dev list
Something like `/db/_design/foo?show_view_stats=true`
could return an additional `_stats` member like:
"_stats": {
"view_a": {
"total_rows":123,
"total_docs_indexed":70,
"update":{
"running":true,
"current_doc":"BCCB65...",
"remaining_docs":22
}
},
"view_b":...
}
The process that updates the design document would force indexing on
foo235 to happen and when it's done then update the view_foo
document to have "current" point to "foo235". It seems like
something that could be better handled inside CouchDB though. Any
thoughts?
I'm not exactly sure what foo234 and foo235 are referring to.
Different views within the `_design/foo` document? What are you trying
to achieve here? :) Selectively triggering view building within a
single design doc?
Cheers
Jan
--
