incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svilen ...@svilendobrev.com>
Subject Re: how do u handle "schema" changes ?
Date Fri, 02 Nov 2012 20:02:17 GMT
> http://wiki.apache.org/couchdb/How_to_deploy_view_changes_in_a_live_environment
waw, reference-counting over indexes... very interesting.

On Fri, 2 Nov 2012 19:28:40 +0100
Dave Cottlehuber <dch@jsonified.com> wrote:

> >> i guess the answer is "it depends", still, any suggestions?
> >
> > I think this is it -- there are so many use cases it is very
> > difficult to generalize. E.g. one area I've struggled with is that
> > large collections -- millions of documents -- introduce significant
> > time constraints for rebuilding view indexes. Changing the "schema"
> > of these documents is not really healthy for a live system. There
> > are several strategies for dealing with just this one use case, and
> > they depend on things like data usage patterns. I've also found
> > that there are significant issues with dependencies between the
> > document structure and other server or client software. These
> > dependencies argue for modification off-line, and simultaneous
> > launch of database, server, and client code.
> >
> > Still, I find that the flexibility of free-form documents, run-time
> > availability of a system even under reindexing, and ease of
> > replication and synchronization make the process of couchdb changes
> > much more tolerable and maleable than sql relational databases.
> >
> > I don't have experience with json schema per se, but I have a
> > feeling that something like it will be important to formalizing the
> > process of document database integrity and evolution. It does seem
> > a bit contrary in these early days of document databases to think
> > of tying documents to scheme definitions (yuck, starts to be all
> > xml-ish), but it does seem like a natural progression for both
> > ensuring database longevity as well as other areas like data
> > sharing and archiving.
> >
> > Cheers,
> > Erik.
> 
> Something I've not tried, for handling clients that aren't yet
> upgraded, would be to expose each "schema change" via a versioned
> RESTish API, and use rewrite rules to point to the appropriate ddocs.
> 
> http://my.api.com/v1/...
> http://my.api.com/v2/...
> 
> As others have suggested the underlying docs are updated separately,
> and then when the migration is complete, I switch in the new ddocs [1]
> and the older clients will be blissfully unaware of the changes.
> 
> [1]:
> http://wiki.apache.org/couchdb/How_to_deploy_view_changes_in_a_live_environment
> 
> A+
> Dave

Mime
View raw message