couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wendall Cada <>
Subject Re: Mass updates
Date Thu, 09 May 2013 20:07:50 GMT
On 05/09/2013 05:52 AM, svilen wrote:
>>>>>> The main concern I have is maintaining a consistent state across
>>>>>> code releases.  Presumably, our data model will change over the
>>>>>> course of time, and when it does, we need to make the several
>>>>>> million old documents conform to the new model.
> a question: do u need to keep the old variant/state too?
> (think bi-temporal stuff)
> that one, and if the once-off conversion process is going to take
> loooong time, it might be better to bite the bullet and allow for
> multiple (e.g. 2) versions of the "schema" to coexist - in both
> server/views and client code. Thus once u already have some doc in the
> new variant, use it. Else, fallback to runtime-conversion.
> i know it isn't easy to organise but otherwise u're fighting reality.
> svilen

This may sound ideal, but in my experience, this can lead to crazy, 
buggy, eventually un-maintainable code. Additionally, this approach ends 
up quickly in a situation where you're not supporting just two schemas, 
but multiple others as well, as you can never guarantee that the schema 
was updated across the entire database.

This has been discussed at my workplace quite extensively recently. 
Ideally, there would be some robust extension to couchdb to handle 
schema changes for large online databases in a sane way.

The real issue here isn't updating the schema in the db docs, it's 
updating the schema and the requisite view indexes. If the schema 
changes break your ddoc code, there isn't any live db solution available 
that can fix this issue. This part of any database maintenance is 
really, really hard work. It's what DBAs do for a living, and is just 
difficult in different ways depending on the database.


View raw message