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 <[email protected]> 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 >
