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: domain of lancecarlson@gmail.com
 designates 209.85.210.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20130509233215.0f6c86cf@svilendobrev.com>
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> <20130509233215.0f6c86cf@svilendobrev.com>
From: Lance Carlson <lancecarlson@gmail.com>
Date: Fri, 10 May 2013 12:53:47 -0400
Message-ID: 
 <CALDn6=jCHRM2EKyCkQ2B1pYjoZmiZD-a-FMZfspcfGG=N-1o2A@mail.gmail.com>
Subject: Re: Mass updates
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc05e8e6afff04dc60039e

--047d7bdc05e8e6afff04dc60039e
Content-Type: text/plain; charset=ISO-8859-1

So, since I'm dealing with this problem now.. I open sourced a small script
that helps at least get couch to Redis and a brain dump of my ideas are
included in the README. Feedback appreciated!

https://github.com/lancecarlson/couchout.go


On Thu, May 9, 2013 at 4:32 PM, svilen <az@svilendobrev.com> wrote:

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

--047d7bdc05e8e6afff04dc60039e--