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?
Wout.
