From user-return-22700-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Nov 2 18:30:36 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E3A8FD3E9 for ; Fri, 2 Nov 2012 18:30:35 +0000 (UTC) Received: (qmail 43904 invoked by uid 500); 2 Nov 2012 18:30:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 43862 invoked by uid 500); 2 Nov 2012 18:30:34 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 43854 invoked by uid 99); 2 Nov 2012 18:30:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 18:30:34 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.82.54] (HELO mail-wg0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 18:30:27 +0000 Received: by mail-wg0-f54.google.com with SMTP id dt10so2241639wgb.23 for ; Fri, 02 Nov 2012 11:30:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=5BOr2peeWTTomuLeIW5LdTpBS85JtTgZ7vHEcADbgZA=; b=gIw9N36UVJlZFM3ECvPkcLLce/6xqVoe/x9steeD1r4RUfa+xShJQQ72syL3GSVMxR JgIL3eGBqNlNRoYJimnH2N3wAGSFo7WDcmo+casEg2Xw8FhWR/r4rHi10KlFbQdgUkb6 /WrQ56tw7GQrprRo6Boa7hvsyciN1rLky5ObUxDZqPDYlgkRxpI/+SWDmRe2W9nSwjJe kFZrLbUvywtov+du0uB0zHL8ecjWpM/R3erMJ3Zin6TQEcjRebG7Bdw9d3hSrr+LZM/I iNaQN90omDwo5SuVC9dp3MIuo/JPSPBDvc5i0oqhzw2UvWr3a8IkZUzAAAy2XxrM1mUE ihWA== Received: by 10.216.198.198 with SMTP id v48mr789388wen.192.1351881007190; Fri, 02 Nov 2012 11:30:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.65 with HTTP; Fri, 2 Nov 2012 11:29:47 -0700 (PDT) X-Originating-IP: [68.5.117.177] In-Reply-To: References: <20121102125801.376ef132@eee-az> From: Mark Hahn Date: Fri, 2 Nov 2012 11:29:47 -0700 Message-ID: Subject: Re: how do u handle "schema" changes ? To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e6d6419a36529304cd875382 X-Gm-Message-State: ALoCoQnkv3qw7tW3GfEaM29rSG5BeFxMRwVdAFN84C8hMYg6j1yFEmlyWcBrZs2rKoWMKOhlJnbT X-Virus-Checked: Checked by ClamAV on apache.org --0016e6d6419a36529304cd875382 Content-Type: text/plain; charset=ISO-8859-1 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 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 > --0016e6d6419a36529304cd875382--