You can try that approach, but I think you will find it more difficult. 
E.g., all of the primitive query classes are written specifically to use
doc-ids.  So, you either need to do you searches separately on each
subindex and then write your own routine to join the results, or you
would need to rewrite all the queries.

I use two different indexing combining techniques:

   1. ParallelReader/ParallelWriter for performance reasons in various
      circumstances; e.g., fast access to frequently used fields (in
      combination with lazy fields -- very useful for fast categorical
      analysis of large samples), fast bulk updates of mutable fields by
      copying a much smaller subindex, etc.
   2. Subindex query rewriting for accessing different types of objects
      in separate indices.  A query on the main index may contain a
      subquery that retrieves objects in a different index and rewrites
      itself into a disjunction of the uid's of those objects.  This
      approach works well assuming you can arrange indexing of fields in
      the main index with subindex uid values, and the disjunction
      expansions are not too large.

Maybe approach 2 is more what you need?  It's pretty simple to do. 
E.g., take a look at MultiTermQuery for a non-primitive query that
rewrites itself dependent on the index.  You need a similar class that
rewrites itself dependent on a different index.

Chuck


wu fox wrote on 06/13/2006 02:18 AM:
> thank you very much Chuck.But I still wondered is there any way that I
> can
> revise ParallelReader so that it do not need the same doc id
> .Can IndexReader comebine different doc according some mapping rules ?for
> example I can override Document method that combine docs from indices
> acoording to same uuid or override some other methods,I think it is much
> easier to do than a writer:) Thank you for your help again.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to