Handle cases where the database is in an inconsistent state

[nolanlawson]

This can happen during replication, e.g. if a parent gets written before a child or a child gets written before a parent. I guess the proper thing to do would be to catch 404s and return nothing for that dependency.

I admit, though, that we are working against the grain of how CouchDB is designed.

[nolanlawson]

Another possible way the current model could become corrupted:

1. User A modifies a child doc, user B modifies the same child doc W (say, changing the parent).
2. From A's perspective, the parent is changed from X to Y. So both X and Y are modified.
3. From B's perspective, the parent is changed from X to Z. So both X and Z are modified.
4. When replicated, the child doc W and parent X are in a conflicted state. Y and Z are not

Clearly, by the time we reach step 4, the conflicts can (potentially) be resolved separately, which would end us up in an even more conflicted state than when we started. Also it's unclear what to do with Y and Z.

[jlami]

I believe not saving the ids on the parent/hasMany side would remove some of these problems. #61 would save the relationships more like CouchDB is designed in my opinion.