Modeling a rooted tree graph about relational-pouch

[stickbyatlas]

Additional reading on this, from 2009: http://seancribbs.com/tech/2009/09/28/modeling-a-tree-in-a-document-database/

The author's first solution is basically what I described. I think relational-pouch might be able to model solution 3, provided all related documents had a generic type with belongsTo pointing to itself, and a member field that points to the underlying related document ID. But this could get really, really messy.

Basically, the documents handled by relational-pouch would represent a database of links, and link documents would contain one key whose value is the ID of the represented document.

This sounds like a terrible idea.

[stickbyatlas]

There's also this, from 2008, which I was toying with in my head before I started looking for a library: http://probablyprogramming.com/2008/07/04/storing-hierarchical-data-in-couchdb

But this takes me further from using a library, and involves writing a lot of original (read: buggy) code, which I'd like to avoid doing.

[nolanlawson]

I believe it recursively loads all ancestors, yes, but you would need to write a test to confirm. Honestly I wrote this code over a year ago and have not looked at it in awhile, so I don't really remember. :)

[nolanlawson]

FWIW I would also say that I consider relational-pouch more of a hack than anything; relational data and CouchDB do not really fit very well together because the concept of master-master replication and relational data do not really fit together. E.g. #24 does a good job of explaining why this is the case. For heavily relational data you may find that CouchDB is a poor fit (although there isn't a synchronizing database in the world that will fit either AFAIK due to theoretical limitations here)

[stickbyatlas]

Yeah, I'm kind of amazed that this level of relational functionality could be packaged into a plugin for a non-relational document store.

Agreed *ouchDB is a poor fit for relational data. However, you can mitigate a lot of potential conflicts depending on how you design the system. My solution is to implement one-way sync from the canonical database to all clients. Canonical data (and its relationships) are treated as read-only. If the user wants to edit a document or its relationships, those changes are captured in a separate document as a 'delta', which is then pushed into a centralized queue. This gives the database maintainer some oversight over which changes they'll apply to the canonical documents, and also ensures that only non-conflicting changes are ever pushed down to the client.

I've learned to avoid bidirectional replication at all costs, because conflicts can get out of hand pretty quickly. Ember's 'data down, actions up' approach to managing state is what inspired me to design the system this way. It's much easier to map out the flow of information when you're pulling down canonical data and pushing up proposed commits that alter that data in a centralized way.

[509dave16]

@stickbyatlas This more recent relational PouchDB package might be better suited to your needs: https://github.com/compactd/slothdb