couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Porritt" <simon.porr...@gmail.com>
Subject Re: hierarchies with inheritance
Date Fri, 02 Jan 2009 22:23:11 GMT
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 : )
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message