Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 72.14.220.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=KQwpWWuwwbVnkOV2Qh4ZSLDzBY1tZcqurGVx0DCwH6CMrZVJ8n5lKCiS+aaoL3q3rHVsGvOj4S/wXrzJCcfCad6e3Gx5qtYghiWzrdGhqpFlnrje4jAMjT+FayImNGI3lG6SUjMw7NfkWeHmKjnrf3Jtc4njyJxXVcBHZLS+39s=
Message-ID: <e282921e0803211719x50956ee8odc9a8c51184fad0f@mail.gmail.com>
Date: Fri, 21 Mar 2008 17:19:01 -0700
From: "Chris Anderson" <jchris@mfdz.com>
Sender: jchris@gmail.com
To: couchdb-user@incubator.apache.org
Subject: Re: Sphinx integration (was: Working on Lucene)
In-Reply-To: <D43C3E2E-6630-403D-BC4B-85DF2AC6B48A@prima.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e282921e0803211455s2ae067fet5aecc94b0561b144@mail.gmail.com>
	 <D43C3E2E-6630-403D-BC4B-85DF2AC6B48A@prima.de>

On Fri, Mar 21, 2008 at 3:26 PM, Jan Lehnardt <jan@prima.de> wrote:
>
>  We should come up with some "schema" (heh) that defines how
>  FT Indexers should behave. I am thinking of a special _design
>  document that sets various configuration variables for the indexer.
>
>  E.g. the views to use for indexing:
>
>  {
>    "_id":"_design/fulltextsearch",
>    "_rev":"123",
>    "_fulltext_options": {
>      "views": ["names", "cities"];
>    }
>  }
>
>  where names and cities were the names of two views. The Indexer
>  then could maintain two separate fulltext indexes based on these
>  views. The HTTP API for querying could look like this:
>
>  http://server/database/_fulltext/names?query="+Me?er -Meyer"
>
>  This is not meant as a definitive RFC, but a starting point for
>  discussions. Please chime in :)

Jan,

I like that idea. There's a use for returning the document that
corresponds to each matching view row, but perhaps someone might want
to use a view key as an index, and the view row's value as the return
value. This could be useful as a lightweight way to return document
summaries on a search results page, with links to the documents
themselves (without sending the whole of every matching document to
the client, when the query is made.)

So some way to configure how to return the results would be handy.
Here's a verbose crack at how one might configure it:

{
  "_id":"_design/fulltextsearch",
  "_rev":"123",
  "_fulltext_options": {
    "views": {
      "names" : {"index":"view-value", "return":"document"},
      "cities": {"index":"view-key", "return":"view-value"}
    }
  }
}


Chris

-- 
Chris Anderson
http://jchris.mfdz.com