A request handler that manipulated the index

[Benson Margulies <be...@basistech.com>]

I am thinking about trying to structure a problem as a Solr plugin. The
nature of the plugin is that it would need to read and write the lucene
index to do its work. It could not be cleanly split into URP 'over here'
and a Search Component 'over there'.

Are there invariants of Solr that would preclude this, like assumptions in
the implementation of the cache?

Re: A request handler that manipulated the index

[Erick Erickson <er...@gmail.com>]

I _think_, and I'm really stretching here, that you'd be OK if you
shared a single
index writer amongst all the requests. Having more than one index writer
going against the same index is a definite no-no.

But atomic updates are a request (admittedly an update request) so it must be
possible, that code might provide some hints?

Erick@NotSureButItSeemsReasonable

On Tue, Apr 2, 2013 at 1:06 PM, Benson Margulies <be...@basistech.com> wrote:
> I am thinking about trying to structure a problem as a Solr plugin. The
> nature of the plugin is that it would need to read and write the lucene
> index to do its work. It could not be cleanly split into URP 'over here'
> and a Search Component 'over there'.
>
> Are there invariants of Solr that would preclude this, like assumptions in
> the implementation of the cache?