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