incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: few doubts
Date Tue, 05 Jul 2011 21:17:01 GMT
> With CouchDB, all you have to do is to create your view within a design
document and it will on its own build the actual "indices" (the views) the
very first time that those views are actually being used.  The next time
that those views are used, then only newly created and/or updated docs need
to be indexed.

Actually, if you change a view in the design doc it rebuilds ALL views in
that doc from scratch for ALL documents.  This was a surprise to me the
first time it happened because my entire application froze up for several
minutes.  I can imagine it happening for an hour with a giant db.  The only
way I can figure out how to get around this problem is to create a second
db, sync the main db to the second, rebuild the views on the second and then
overwrite the main db file with the second db file.  Kind of a pain.

On Tue, Jul 5, 2011 at 11:17 AM, Randall Leeds <randall.leeds@gmail.com>wrote:

> I like everything you've said in these last three messages which were
> meant to be one. :)
> You should make it a blog post. For real.
>
> On Tue, Jul 5, 2011 at 00:32, Zdravko Gligic <zgligic@gmail.com> wrote:
> > oh, i hate gmail, as it seems to react to certain key combinations ...
> >
> > Focus - It seems that CouchDB has been purposely designed with "single
> > mindedness in mind".  The approach seems to be that it can be most
> > efficient if its various functions and its various tasks do small
> > amounts of work in the most efficient way possible.  So, it would seem
> > that writes keep on writing to the end of file, instead of flipping
> > through it and trying to over-write and update in place existing docs.
> >  Again, in order to be as efficient as it can be with those writes, it
> > foregoes updating the views (the same way that an RDBMS would update
> > all of the related indices as part of its record update) and leaves it
> > for another process which will concentrate on doing just that.  So, it
> > seems that "context switching" or not having to do much of such
> > switching is where it gets lots of it processing efficiency.
> >
> > Again, I am most anxious to see how my noob understandings check out
> > with technical realities.  ;)
> >
> > HTH,
> > teslan
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message