: I think the 'updating documents' issue is almost always related to
: unique document updates, where there exists some "primary unique key"
: for the document. Is this true?
: if so, it would be easy to add the following to IndexModifer:
:
: addDocument(Document)
: updateDocument(Document)
the problem is that when people talk about "updating" a document, they are
ususally refering to the RDBMS notion of updating a single "field" ...
something that's tehoreticaly impossible given the inverted index model ..
in practice it can be emulated by deleting the old "version" of the doc
and adding a new "version" of the doc where the new version is just the
stored fields from the old doc modified by whatever field has changed.
typically this is done in the application layer above Lucene, but i
suppose we could provide for a convinience layer to make it easier for
folks ... the existing Document API as we know it really wouldn't work
though.
Solr has an open issue (which i haven't looked at in a while) that is
trying to address this (again: in the application layer) but the end user
Solr API is a lot simpler then the low level Lucene API, and Solr has a
schema to work with which can let it do things like reject attempts to
update docs if hte Schema has fields which are indexed but not stored...
https://issues.apache.org/jira/browse/SOLR-139
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
