I never change old docs. I just make sure my code can handle the old versions. So I have multiple schemas at once. I don't see any reason to go through and update the docs since the app does the same thing on the fly.
On Fri, Nov 2, 2012 at 10:01 AM, Erik Pearson <[email protected]> wrote: > > i know it may sound self-contradictory for couchdb being schemaless .. > > > > but documents that go into it do have structure/schema. > > And once that changes - simplest example being renaming of some field - > > what's the recipe? > > i know it all from the sql land, but this is different. > > > > update the documents ? > > or make all code - both outside and inside couchdb (views etc) - > > accept/handle both old and new? > > > > 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. > > > > > ciao > > svilen >
