Wout Mertens wrote:
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?
Dealing with whole documents at once.
To modify a small part of a single Jit, one would need to download the
entire document, modify that small chunk of data, then PUT that entire
document back to the server.
It leads to the conflict issue where you have to deal with the fact that
someone might have modified a completely irrelevant part of the document
in the meantime and you hit a conflict as a result.
It's also extremely inefficient since you have to transfer (twice) and
handle a document that may contain thousands of Jits just to modify a
tiny piece of it. Not to mention the duplication of the document every
time you make a minor modification.
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.
Views are actually fairly wasteful on memory for tasks which aren't to
heavy on the CPU to do at query time. Especially since to index an
entire document with a view you basically duplicate it a pile of times.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
