I don't think you need to add to a term vector.
I guess what I was thinking (and this is just a guess not knowing your
architecture) is that you could have a TokenStreamFilter/Analyzer that
took in the appropriate term vectors, along with your runtime
incremental information. Then, as you are "in
Lucene's scalability is not in question. The simple solution of
rebuilding the string of terms is what I referred to as not being
scalable. For instance, consider the following term vector:
termFreqVector (freq {myTermField: red/69, green/79, blue/899})
Recreating a string with 69
I don't think you need to parse the toString, you have the
TermFreqVector object which lets you access the appropriate pieces of
information (string, freq). You could then turn around and delete/index
the new document based on the vector with the increments. I don't know
whether it would scale or
Adding new terms and re-indexing the document is the desired behavior.
One (non-scalable) solution would be to parse the toString of the
termFreqVector (freq {myTermField: red/2, green/1, blue/1}) and create a
new string representation of the expanded terms: (red red green blue)
This obviously
Is your intent to persist the changed vector somehow or just use it in
your application for the immediate search?
TermFreqVector is an interface, so if you aren't persisting, I would
write a wrapper class around the one that is returned by Lucene that has
add/set methods on it for manipulating the
How would one go about adding additional terms to a field which is not
stored literally, but instead has a termFreqVector? For example:
If DocumentA was indexed originally with:
myTermField: red green blue
termFreqVector would look like:
freq {myTermField: red/1, green/1, blue/1}
Now,
