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 <[email protected]>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 <[email protected]> > 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 : ) > > >
