> > IndexableField really shouldn't be a subclass of whatever class is
> > returned after a sarch is done ... the methods used for accessing the
> > "stored" value of a returned document make as little sense in the
> > context of IndexableField as the setBoost/Reader/TokenStream  
> > functions of
> > Document currently make when a search is executed.
> >
> > when all is said and done: an IndexableField and a SearchResultField
> > shouldn't have anything in common except *maybe* that they both have a
> > fieldName.
> 
> Actually I think they do share alot more than just name of the  
> field?  Accessing the "stored" value of a document is exactly what  
> indexing needs to do when it indexes the document in the first  
> place?  Ie, a "stored" document "looks alot like" the document at  
> indexing time that had been stored.  And things like isTokenized,  
> isTermVectorStored, isStoreOffsetWithTermVector, isBinary are  
> actually preserved in the index and known to the reader, so it's  
> worth having these methods available at search time?
> 

 
Another case where it makes sense to mix read/write responsibilities is setting 
backing storage for SearchResultField, or in other words, "Dear lucene 
Document/LazyField, here is my byte[], and this is an offset into this array 
where I would like you to store the content of the stored field when you read 
it from your mighty Directory, and please let me know how many bytes you have 
read...."

for something like this the, the same setter you need for IndexableField can be 
used  in SearchResultField... sure, SearchresultField can be mutable, but then, 
is this not just repeating IndexableField methods?

tough one, gut feelings are to have this separation, examples show that one 
class would do the job (like Doug's initial design, if my memory goes that far 
:)
 





      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/


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

Reply via email to