couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Heger <will.he...@gmail.com>
Subject Re: JavaScript 1.8.5 and Upgrades
Date Wed, 15 Aug 2012 19:56:49 GMT
I'm going to try this tonight when I can take the DB offline and
report back because the results may be interesting.

This was exactly the piece of terrible advice I was looking for!

Thanks Adam,
-Will


On Wed, Aug 15, 2012 at 3:38 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> On Aug 15, 2012, at 9:32 AM, Will Heger wrote:
>
>> After pushing some UTC Date() containing reduce code to a server, I
>> discovered that the server was using 1.8.0 SpiderMonkey rather than
>> 1.8.5, balls!
>>
>> So, my impression from the docs is that CouchDB needs to be compiled
>> with a JavaScript engine, there is no swapping up to 1.8.5 from 1.8.0
>> (but please correct this if I'm wrong, I'd much rather swap the engine
>> than rebuild a running couchdb).
>>
>> So here's my question: What is the a typical or best practice for
>> performing an upgrade to CouchDb?   Luckily, the server isn't a 24/7
>> instance, so I have some time to take it down.  But is it:
>>
>> 0. doubtful, but is there a way to ugrade the SpiderMonkey in situ?
>> 1. Is there a upgrade process or 'upgrader' in couchdb somewhere?
>> 2. If not, do I backup replicate, stop, and build, and "make install"
>> overtop? Or...
>> 3. Is it option 2, but I need to eradicate the existing installation,
>> and if so, how does one eradicate completely couchdb (one installed
>> from source, IIRC)?
>>
>> Apologies in advance if these are answered through Googling, but I
>> didn't find a succinct explanation.
>>
>> And thanks in advance for any assistance.
>>
>> Best regards,
>> -Will
>
> Hi Will, if you were so inclined you could install SM185, drop in a new couchjs binary
that links against it, do a killall to knock out any running couchjs processes, and the server
should start using your new build of couchjs for all new requests.  The core database isn't
linked to SpiderMonkey in any way.  You'll lose any requests that were using a JS process
(_show/_list/_update, blocking on a _view build, etc.), but that's about it.
>
> I probably made a hundred sysadmins spill their coffee just now, but I thought I'd throw
it out there anyway.  Cheers,
>
> Adam

Mime
View raw message