couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wout Mertens <>
Subject Re: Erlang vs Scala
Date Tue, 14 Apr 2009 08:38:27 GMT
Hi Daniel,

On Apr 13, 2009, at 7:01 AM, Daniel Friesen wrote:

> In CouchDB we would have needed a structure similar to:
> document aaa: { "isa": "jit", "state": {}, "children": ["bbb",  
> "ccc"] }
> document bbb: { "isa": "jit", "state": {}, "children": ["ddd"] }
> document ccc: { "isa": "jit", "state": {}, "children": ["ddd"] }
> document ddd: { "isa": "jit", "state": {}, "children": [] }
> But unfortunately we can't go grabbing data hierarchically without  
> doing a pile of queries, or complicating the data structure in a way  
> that I cannot sanely complicate the program itself by using when I  
> have other options. Avoiding the huge piles of queries and  
> overcomplicated data structures was the whole reason behind moving  
> away from MySQL and into using non-traditional databases.
> In the XML database instead of the structure before I can place all  
> the jits into one document for the site (because I can modify  
> individual parts of it without worrying about conflicts in other  
> parts of the document) and make use of XQuery to to iteration and  
> recursion and return whatever I need.
> <site id="...">
> <jits>
> <jit id="aaa"><state/><children><jit>bbb</jit><jit>ccc</jit></

> children></jit>
> <jit id="bbb"><state/><children><jit>ddd</jit></children></jit>
> <jit id="ccc"><state/><children><jit>ddd</jit></children></jit>
> <jit id="ddd"><state/><children/></jit>
> </jits>
> </site>

I'm confused I think. Is it correct to say that you compile all jits  
into a master document per site? What would prevent you from using the  
same technique with CouchDB?

> So querying for the jit ID by document id in couch is equivalent to  
> `doc(...)/site/jits/jit[id="..."]` in XQuery. But because of FLWOR  
> and the other parts of XQuery I should theoretically be able to deal  
> with the recursive nature of our data on the database side.

I think you can do the very same thing in CouchDB using one doc per  
site. You can use views to generate the recursive list of jits you  
need to load.

As for atomicity, a document is atomic for CouchDB, so that would help  
as well?


View raw message