Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <64a10fff0901021435j59c161f7x17930e05c37c1aef@mail.gmail.com>
Date: Fri, 2 Jan 2009 17:35:27 -0500
From: "Dean Landolt" <dean@deanlandolt.com>
To: user@couchdb.apache.org
Subject: Re: hierarchies with inheritance
In-Reply-To: <30f836430901021423i75a97aaeg6c49e530ed6abd32@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_167520_8484113.1230935727977"
References: <30f836430901021245l70c287d5r1693785246154557@mail.gmail.com>
	 <e2111bbb0901021359g1b19399bl9987e449daac0bb4@mail.gmail.com>
	 <30f836430901021423i75a97aaeg6c49e530ed6abd32@mail.gmail.com>

------=_Part_167520_8484113.1230935727977
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

well, you know, there's this little known property about JSON...referencing

http://www.json.com/2007/10/19/json-referencing-proposal-and-library/

i haven't given too much consideration on how to adapt something like this
to couch, but if you come up with a convention, or use the one defined by
json-referencing, you could just dereference what comes out of couch on the
client (or perhaps even better, automagically using an action server) and
you've got your inheritance

of course, dereferencing couldn't happen inside a view, so you're on your
own there -- but if you're looking for ad-hoc querying, you may be barking
up the wrong database tree anyway


On Fri, Jan 2, 2009 at 5:23 PM, Simon Porritt <simon.porritt@gmail.com>wrote:

> Damn, I was hoping someone would write back and say, "well, you know,
> there's this little known property about JSON ordering....".
>
> anyway.
>
> the problem with cloning a config is that it creates orphans, ie. documents
> that are now blind to changes in the parent document.  if Australia all of
> a
> sudden switches back to using Pounds, or perhaps joins the Euro, i'm left
> in
> a pickle (extreme examples always serve to illustrate my woes the best!).
>
> so why not update all the children when a parent document changes a value?
> it just seems....nasty.  who knows how deep the inheritance may go etc.
> plus, again, its client side.
>
> in every other way but this CouchDB is a perfect solution to the problem.
> it seems a shame.
>
> thanks
>
> Simon
>
>
> On Fri, Jan 2, 2009 at 4:59 PM, Paul Davis <paul.joseph.davis@gmail.com
> >wrote:
>
> > Simon,
> >
> > Nothing that wouldn't require at least some client side processing.
> > (No Map/Reduce tricks spring to mind anyway.)
> >
> > Though in general what you probably want instead of the hierarchy is
> > to be able to clone a config and then only change what needs changing.
> > If you're coming from RDBMS land, that probably breaks your better
> > sense of normalization, but that's a step we all have to overcome in
> > the transition :D
> >
> > HTH,
> > Paul Davis
> >
> > On Fri, Jan 2, 2009 at 3:45 PM, Simon Porritt <simon.porritt@gmail.com>
> > wrote:
> > > I'm wondering if anyone has some tricks up their sleeve to do with
> > > hierarchical data and inheritance.
> > >
> > > I've seen this on the Wiki:
> > >
> > > http://wiki.apache.org/couchdb/How_to_store_hierarchical_data
> > >
> > > So the scenario I'm interested in is something like this:
> > >
> > > i have websites in several countries.  there is a unique set of
> > operational
> > > settings required for each site - two good examples are the language it
> > uses
> > > and the currency it trades in.  i want to store these settings in
> couchdb
> > in
> > > such a way that each site has a "parent" site, from which it derives
> > > values.  i will have one document that models the top of the
> inheritance
> > > hierarchy, and in it i will put default values - let's say USD and US
> > > English.  then i will have a document for my Australian sites.  it will
> > not
> > > bother to override the language, but it will want to say that currency
> is
> > > AUD.  so now i have this:
> > >
> > > root:
> > >
> > > {
> > >  _id:"root",
> > > _rev:"123",
> > > parent:null,
> > > language:"en_US",
> > > currency:"USD"
> > > }
> > >
> > > australia:
> > >
> > > {
> > > _id:"australia"
> > > _rev:"123",
> > > parent:"root",
> > > currency:"AUD"
> > > }
> > >
> > >
> > > is there a fancy way of writing a view that would allow me to get the
> > > "australia" document returned with a language value of "en_US"?  I know
> i
> > > can do this in the client : )  But i don't want to - and that is
> because
> > i
> > > like the idea of one of my business people coming along and being able
> to
> > > run "ad-hoc" queries about our data.  what if someone suddenly decided
> > they
> > > wanted to know how many sites are using US English, for example?  if
> > every
> > > document had the language value set it would be a snack, but then all
> the
> > > power of inheritance would be lost.
> > >
> > > does this make sense?  i hope i've explained it adequately.
> > >
> > > thanks
> > >
> > > Simon
> > >
> > > ps. i know i can do this in the client : )
> > >
> >
>

------=_Part_167520_8484113.1230935727977--