couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayson Barley <>
Subject Re: how do u handle "schema" changes ?
Date Fri, 02 Nov 2012 15:36:21 GMT
Maybe I am doing something that doesn't make sense, but the way I do it is
through show and validation functions. Clients are required to access
specific documents through a show function. This allows me to update the
schema on documents reads. The client will have the version that they
should have. Then when they submit a change, the validation function makes
sure it fits my schema. If I want to update every document in the store, I
can just iterate through each document in the list and immediately submit
it again.

On Fri, Nov 2, 2012 at 5:35 AM, svilen <> wrote:

> > > And once that changes - simplest example being renaming of some
> > > field - what's the recipe?
> >
> > Our recipe is a small script that iterates over every document in the
> > database that modifies it to comply with the new schema. We do this as
> > part of upgrading the system living on top of CouchDB.
> >
> > Besides this, we have a single document containing the schema version
> > and some status fields indicating if an upgrade is running or if it
> > has been run failed.
> this is fine and would work if all instances of the system on top are of
> same version - or there is just single instance.
> but with replication and all the distributed possibilities (think
> phones etc).. another approach might be needed. Maybe allow multiple
> schemas to co-exist.. somehow. Seems it becomes a question of schema
> being the protocol, and if/how multiple variants of that can live
> together. And/Or considering very hard whether a schema is
> futureproof enough before publishing the software using it.. hmmm
> ciao
> svilen

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message