couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: how do u handle "schema" changes ?
Date Fri, 02 Nov 2012 18:28:40 GMT
>> 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