Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 9 May 2013 23:32:15 +0300
From: svilen <az@svilendobrev.com>
To: user@couchdb.apache.org
Subject: Re: Mass updates
Message-ID: <20130509233215.0f6c86cf@svilendobrev.com>
In-Reply-To: <518C0216.9000607@apache.org>
References: <518B16F5.2040306@alumni.gwu.edu>
	<CAJ_m3YDamHmbJK2pfxtTJ=Jy3OA9MxqRwX_QWAhqqnV+vMorCQ@mail.gmail.com>
	<CAG+HO1yx-0SNziDPYkwNT7KCH7LsSZx7-Yvb724mBDthLMs6oQ@mail.gmail.com>
	<CABvT1DEMTgyDvEBH3UEwFVFxZCH+YM1z7rYUBGDB3FMSY+aX8w@mail.gmail.com>
	<8471588272415020431@unknownmsgid>
	<20130509155252.74edbd0e@svilendobrev.com>
	<518C0216.9000607@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

yeah i know. i've been through it, needing temporaly-versioned
code stored in a db, apart of the data for that time-period.. i know
what it is. Near to impossible - still, it's the only correct one.

> Ideally, there would be some robust extension to couchdb to handle 
> schema changes for large online databases in a sane way.
btw i read that something like virtual views is going to be
made.. one that would help multi-pass queries (which now are made just
via artificial temporary dbs). Maybe these multi-version schemas are
kind of that..

On Thu, 09 May 2013 13:07:50 -0700
Wendall Cada <wendallc@apache.org> wrote:

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