On 11/18/09 3:45 AM, Jan Lehnardt wrote:
On 18 Nov 2009, at 11:46, 7zark7 wrote:
Bit of a design question, hope you can provide some guidance:
I'm writing an internal wiki-like web application, and one of the use-cases is
to comment on a document.
Domain model is simple:
a Comment class with text, date, and a collection of child comments.
My first implementation stores the comment tree in a single document, since it is very
easy to serialize and deserialize, and the comment tree itself can be thought of as a
holistic "document".
This works great, but now running into an issue on how to best support revision
conflicts when multiple people are commenting at the same time.
If I were to keep the tree stored in a single document, I would have to load
the two conflicting versions in code, manually combine the trees, and then save
a new version, correct?
From a storage-perspective, it seems it would be simpler then to store each comment as
its own document, with a "foreign key" of sorts pointing to a parent comment,
which would be much less likely to have conflicts.
But then it seems I'm forcing a relational model into a document-based DB.
Any thoughts on this?
Christopher Lenz has a great discussion about this very problem:
http://www.cmlenz.net/archives/2007/10/couchdb-joins
Cheers
Jan
--
Perfect, thanks Jan
