27 jul 2007 kl. 02.18 skrev Grant Ingersoll:
I think one thing I wonder about is if there is a way it could be a
standalone contrib package or maybe there is a way to separate out
the interface changes from the InstantiatedIndex stuff? That way
you could lobby for InstIndex as a contrib, and then a separate
patch for the API changes.
That is sort of what I tried with 581. I want to point out that one
should no longer be looking at that patch. Since it was set no-fix
and merged back with 550 I have replaced the generalization with
aggregations (i.e. Directory does not extend index, there is a new
class, DirectoryIndex, that points at an instance of Directory) and
some other things in order to minimize the impact on core. It is
visible in the UML diagram.
I'd be more than happy to spend the week required to bring 550 up to
speed with the trunk, clean it up and split it up in multiple
patches, but only if I knew that the core changes would be accepted.
Something like this:
* Core changes (complete definalization of Term, Document and
IndexReader + IndexWriterInterface)
* Index (factory class for reader and writer for unison index handling)
* InstantiatedIndex (extends Index)
* NotifiableIndex (decoration layer on top of index)
* Active results cache and the other stuff that is just ideas on top
of the two prior items.
By the looks of the issue, you had a lot of comments and good
input, do you feel all the issues have all been addressed? Just
asking...
I do. At least I did the last time I was looking at the code, 6
months ago or so.
Also, does Mike M's changes affect how you would do these things?
Not sure what you are refering to. 550 is however fairly isolated
from the rest of Lucene.
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
