couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Hodgson <>
Subject representing many-to-many relations with concurrent inserts
Date Mon, 30 Nov 2009 21:21:31 GMT
Hi list,

I'm a newbie with couchDB, so please forgive any transgressions. Also, I'm
cross-posting this question to Stack Overflow,
hope that's not considered rude.

Let's say I'm writing a log analysis application. The main domain object
would be a LogEntry. In addition. users of the application define a LogTopic
which describes what log entries they are interested in. As the application
receives log entries it adds them to couchDB, and also checks them against
all the LogTopics in the system to see if they match the criteria in the
topic. If it does then the system should record that the entry matches the
topic. Thus, there is a many-to-many relationship between LogEntries and

If I were storing this in a RDBMS I would do something like:

 id int,



 id int,

CREATE TABLE TopicEntryMap (

 entry_id int,
 topic_id int

Using CouchDB I first tried having just two document types. I'd have a
LogEntry type, looking something like this:

  'type': 'LogEntry',

  'severity': 'DEBUG',

and I'd have a LogTopic type, looking something like this:

  'type': 'LogTopic',

  'matching_entries': ['log_entry_1','log_entry_12','log_entry_34',....],


You can see that I represent the relationship by using a
matching_entriesfield in each LogTopic documents to store a list of
LogEntry document ids.
This works fine up to a point, but I have issues when multiple clients are
both attempting to add a matching entry to a topic. Both attempt optimistic
updates, and one fails. The solution I'm using now is to essentially
reproduce the RDBMS approach, and add a third document type, something like:



This works, and gets past the concurrent update issues, but I have two

   1. I worry that I'm just using this approach because it's what I'd do in
   a relational DB. I wonder if there's a more couchDB-like (relaxful?)
   2. My views can no longer retrieve all the entries for a specific topic
   in one call. My previous solution allowed that (if I used the include_docs

Anyone have a better solution for me? Would it help if I also posted the
views I'm using?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message