couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Barnes <mrtr...@gmail.com>
Subject Re: few doubts
Date Wed, 06 Jul 2011 00:00:32 GMT
I have written a PHP script for my application to do this seamless update:
https://gist.github.com/1066246
I find it very useful! My rebuild time is about 30 minutes, so if it 
blocked I'd have users screaming at me in short order.

One or two aspects of the script are app-specific, but it should be 
fairly easy to understand and to tailor for your own use.

-Patrick



On 6/07/2011 7:44 AM, Mark Hahn wrote:
> Cool.  That is much easier.  Still a bit of a pain.  It would be nice if it
> did this automatically on every view change.
>
> On Tue, Jul 5, 2011 at 2:31 PM, Sean Copenhaver
> <sean.copenhaver@gmail.com>wrote:
>
>> CouchDB actually relates a design document to it's views by I believe a
>> hash
>> of the design document contents (not the id). The wiki actually has a how
>> to
>> for deploy view changes in a live environment:
>>
>>
>> https://wiki.apache.org/couchdb/How_to_deploy_view_changes_in_a_live_environment
>>
>> On Tue, Jul 5, 2011 at 5:17 PM, Mark Hahn<mark@boutiquing.com>  wrote:
>>
>>>> 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
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> “The limits of language are the limits of one's world. “ -Ludwig von
>> Wittgenstein
>>
>

Mime
View raw message