incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Pearson <>
Subject Re: how do u handle "schema" changes ?
Date Fri, 02 Nov 2012 20:44:06 GMT
> 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.

Nice approach, Mark. Attests to the freedom couchdb gives you to do it
your own way.

I can see the advantage of this in, e.g., distributed apps where you
can't control who has what. In my world of web apps, I would probably
opt for biting the bullet and versioning the database, server, and
client in (relative) synchrony. However, there are many changes that
can be made which don't break client code, and the "progressive
enhancement" approach can work quite well too. E.g. lots of my "code"
lives in templates, either server or client side. Changes in the
structure of a document usually requires template restructuring, but
new fields can be worked around by making sure the absence or presence
of that field is handled. Actually, since most of my docs have quite a
few optional fields, that is the modus operandi already. I would agree
that changing the structure of a document after it is in operation is
not fun, and should be avoided.


> On Fri, Nov 2, 2012 at 10:01 AM, Erik Pearson <> 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

View raw message