How to organize views

[Ask Bjørn Hansen <as...@apache.org>]

Hi,

I'm using 0.9.0 (svn trunk).    What's the best way to organize the  
design documents?  In the DB I'm working on I have three design  
documents (with 1, 2 and 3 views respectively); roughly organized by  
"which data is indexed".    Does that make sense?

If I understand it right, then each design document updates  
separately, but all views in a design doc are updated together.    
Given that, does it make more sense to split them up further; or do I  
get some performance benefits from updating more of the documents  
together?


  - ask

Re: How to organize views

[Jan Lehnardt <ja...@apache.org>]

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
--

Re: How to organize views

[Ask Bjørn Hansen <as...@apache.org>]

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" }

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?


  - ask

-- 
http://develooper.com/ - http://askask.com/

Re: How to organize views

[Paul Davis <pa...@gmail.com>]

Technically speaking, you would be incurring less overhead if you had
all views in one design document vs. spread out. The reason being that
for each design doc, documents have to be serialized to json and then
the results are de serialized.

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.

The second method is running on the idea that design docs have a 1 to
1 correspondence to applications.

Paul

On Sun, Nov 2, 2008 at 5:23 PM, Ask Bjørn Hansen <as...@apache.org> wrote:
> Hi,
>
> I'm using 0.9.0 (svn trunk).    What's the best way to organize the design
> documents?  In the DB I'm working on I have three design documents (with 1,
> 2 and 3 views respectively); roughly organized by "which data is indexed".
>  Does that make sense?
>
> If I understand it right, then each design document updates separately, but
> all views in a design doc are updated together.   Given that, does it make
> more sense to split them up further; or do I get some performance benefits
> from updating more of the documents together?
>
>
>  - ask
>