Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <5e6458d0902120816u3547b3caxd997890308b7268f@mail.gmail.com>
References: <4b307fd10902120242v3bbbc93fs92c88503eb632fe9@mail.gmail.com>
	 <64a10fff0902120746j187aff2bpc1e5585b32007497@mail.gmail.com>
	 <5e6458d0902120759r24d7010evef257a4674d94187@mail.gmail.com>
	 <64a10fff0902120805l70905938u2ee8ea285e3fb26e@mail.gmail.com>
	 <5e6458d0902120816u3547b3caxd997890308b7268f@mail.gmail.com>
Date: Thu, 12 Feb 2009 11:31:13 -0500
Message-ID: <64a10fff0902120831q3a16e5dch98bf8f61869fc432@mail.gmail.com>
Subject: Re: playing with tags
From: Dean Landolt <dean@deanlandolt.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd6abb2b344ae0462bb3f02

--000e0cd6abb2b344ae0462bb3f02
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Feb 12, 2009 at 11:16 AM, Kerr Rainey <kerr.rainey@gmail.com> wrote:

> 2009/2/12 Dean Landolt <dean@deanlandolt.com>:
> > Perhaps in this scenario, but take a feed reader, for instance. When a
> user
> > is tagging feeds, it is subject to change at a much different rate than
> the
> > otherwise static content. Even in a single user scenario, once
> replication
> > is introduced (say, to a local instance of the app), it's easy to imagine
> a
> > situation where things get messy. Then imagine read/unread metadata, and
> all
> > the others types of user data associated with this otherwise static
> content.
>
> Obviously you need to fit the solution to the problem.  Storing meta
> data in a doc is not inherently a problem.  Storing *any* data that
> has high contention on a single document is a problem, but that's just
> basic CouchDB in the same way that you wouldn't store the comments on
> a single blog post doc.  If your meta data is highly contended then
> you need to find another way round it.  But all this is a non sequitur
> from the problem of getting AND semantics for keys in view lookups.


Perhaps this does belong in a different thread, but the example just
reminded me of the general design question -- AND semantics and view
intersections by value are a pretty big part of it.

Take read/unread state. Obviously you don't want to store this in the doc --
each read/unread event is separate from the doc. So you could keep separate
docs like this:

{
   "_id": "4b3d17d0269e0fa23072abec8859f447",
   "_rev": "1211529288",
   "at": "2009-02-02T08:07:56Z",
   "class": "state",
   "entry": "http://example.com/1",
   "read": false
}

...or some such -- that's just an implementation detail. You can reduce
these state events down into one value (also taking into consideration, for
instance, when an update field on the doc is newer than the latest read
state).

If you just want to get all unread feeds, AND semantics would be pretty damn
helpful (yes, I know you could do a multi-key get and filter at the client).
But when you want to know which feeds are unread for a view it's unavailable
to you (that's what I meant by map/reduce/map). Paul's ideas about values
indexes are one possible way to get around this. I was just wondering
whether there was another approach I'm missing.

--000e0cd6abb2b344ae0462bb3f02--