couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@mfdz.com>
Subject Re: Sphinx integration (was: Working on Lucene)
Date Sat, 22 Mar 2008 00:19:01 GMT
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

Mime
View raw message