There is also the possibility of keeping tags with the original
documents and having them individually updated without having to
resend the original full text as well: <https://issues.apache.org/
jira/browse/SOLR-139>
And yeah, Peter is a solr4lib kinda guy, doing some way cool stuff
with Lucene and Solr already: <http://peel.library.ualberta.ca/
search/?
search=raw&pageNumber=1&index=peelbib&field=body&rawQuery=dog&digstatus=
on>
With separate indexes we're back to the relational model that adds a
lot of complexity. For example, I cannot use MoreLikeThis with tags
to allow commonly tagged objects to be considered similar. I'm sure
there are other ways to implement that sort of thing, though I've not
thought it through.
Erik
On Feb 13, 2007, at 6:17 PM, Yonik Seeley wrote:
On 2/13/07, Binkley, Peter <[EMAIL PROTECTED]> wrote:
I still wonder if there's a good way of storing the tags outside the
Lucene index and using them via facets whose bitsets are manipulated
directly rather than being populated from the index. In my project,
reindexing a documents whenever a user adds a tag is very very bad,
since we're indexing potentially hundreds of pages of full text in
the
body field of the document. A solution that gets the tag into the
system
immediately without forcing a reindexing of the document is
essential.
Interesting... what are you indexing that is that large, the book
contents?
You could build a custom request handler and store tag info outside
the index. You could also store it inside the index in separate
documents as Erik does with Collex.
For a more general solution, I'm thinking a separate lucene index
might be ideal.
-Yonik
