Damien Katz

I've been watching too much election coverage... when I read your topic, I saw "Republican Insight." *sigh* :-)

I'm turning dorkinese,
I think I'm turning dorkinese,
I really think so!

If the system is peer-distributed, then what about conflicts within the tree itself? E.g., when two users on one server make a change to a single field, and two users on another server make changes to the same field. Notes has edit conflicts, and replication conflicts to handle this which is one of the reasons I've always disliked the document storage model for production data.

I love the way Wikis handle conflicts and revisions. It really does not matter much which is the winner if there is an audit trail with diff highlighting.

with the Wiki style updates there is no semantic difference between editing a document normally and a conflict happening. When you post an updated version that new version "conflicts" with the existing version. It would be possible to keep all versions, perhaps purge old things on a schedule, or even keep everything as a stack of diffs. I think the Notes style conflict handling does make sense, but it breaks applications too often. I think that conflicts should not show up in computed tables, or when retrieving a document, but the prior versions should be retrievable with a url syntax below document level. Maybe http://couchserver/somedatabase/some_doc_name:$revisions
for a special computed table of revision information about that document including revisionID, datetime, username etc. and
http://couchserver/somedatabase/some_doc_name/$revisionID to retrieve a particular revision of that document.

Using a tree for the revision ids sounds good. I can see how that helps determining what revision differences across many replicas. From your description though, I'm not sure how you preserve the losing conflict information. Do you keep the losing information on the winning document, tagged against the revision tree?

On a related note, if you had a mechanism for tagging data against a revision, does that mean that you could have a built in revision control, whereby all revisions are stored. Obviously this would be a big overhead, and should only be offered as an option, but it would be extremely useful on many use cases.

I was wondering also if you had any more thoughts on how you see Couch in the market place. You have said before that you see Couch as an end user technology that can allow end users to build useful tools applications themselves. You've also posted before on the Turing Tarpit of having a framework so flexible that you get no benefit from using it. As a Domino developer, Couch is sounding very interesting and I'm planning to have a good dig around it. How do you see the a role of application developer using Couch. Any plans to offer other language APIs alongside the REST one?

"Do you keep the losing information on the winning document, tagged against the revision tree?"

Correct, the losing information (and actually the leaf nodes of all revision branches) are kept around and merged into a single document entity that's replicated around.

The simple algorithm for selecting the winning revision (the one that is actually "displayed" in the database) is to find the non-deletion revision node with the longest path from the root. (This causes deletion conflicts to always "lose" and ensures revisions with the most edits win. It's an arbitrary criteria, but it is determinstic and mostly works like people would expect). So even though a winner is selected, the losers are kept around to be resolved.

Later, the conflicts can be merged/resolved by a tool or a human, and to clear out conflict branch you simply append a deletion revision to end of that losing branch, thereby discarding the conflicting data (which could have been merged onto the winning branch or discarded completely).

how would this interact with multiple saves of a document, like a periodic autosave?
so for example I open up version 2 of a document and start editing it, every 10 minutes a "save" is performed and after an hour I save and close what I am doing. Would all the interim saves be branches of the tree?

Multiple saves work just fine. Each save will be a new revisionid node added to the main revisionid node, so it becomes the new winning leaf.

For the client, each time to you save the document it just needs to keep track of the last revisionId. When it saves a new revisionid is created and sent back to the client, the old data is discarded (though recoverable, until database compaction old revisions are still available on disk). As long as the client keeps track of the last revision id everything works.

If someone edits the document from underneath, then the client gets back a conflict error when it tries to save. The client can do several things: it can update anyway and allow the update to become a conflict loser, it can force an update to be the conflict winner, it can merge the conflicts, or it can ask the user what to do.

I am not sure how you are going to handle attachments, will they be part of the document and subject to the same revision mechanism, or will they be separate, and associated with the document revision tree as a whole?

Alan, regarding your earlier comments about the prior revisions, CouchDb will make the old revision data retrievable as long as they are are still on disk. So the revision history will maintain the whole revisionID tree, but only the data in the last revision of the branches (the winner and the conflicts) are actually guaranteed to be on disk.

Conceptually attachments are handled uniformly with the conflict data. The losing conflict document's attachments are also available like everything else.

It just works.