[
https://issues.apache.org/jira/browse/SOLR-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878448#action_12878448
]
Lance Norskog commented on SOLR-1949:
-------------------------------------
Does commit with expungeDeletes=true solve this?
> overwrite document fails if Solr index is not optimized
> -------------------------------------------------------
>
> Key: SOLR-1949
> URL: https://issues.apache.org/jira/browse/SOLR-1949
> Project: Solr
> Issue Type: Bug
> Components: update
> Affects Versions: 1.4
> Environment: linux centos
> Reporter: Miguel B.
>
> Scenario:
> - Solr 1.4 with multicore
> - We have a set of 5.000 source documents that we want to index.
> - We send these set to Solr by SolrJ API and they are added correctly. We
> have field ID as string and uniqueKey, so the update operation overwite
> documents with the same ID. The result is 4500 unique documents in Solr. Also
> all documents have an index field that contains the source repository of each
> document, we need it because we want to index another sources.
> - After add operation, we send optimization.
>
> All works fine at this point. Solr have 4.500 documents at Solr core (and
> 4.500 max documents too).
>
> Now these 5.000 sources documents are updated by users, and a set of them are
> deleted (supose, 1000). So, now we want to update our Solr index with these
> change (unfortunately our repository doesn't support an incremental
> approach), the operations are:
>
> - At index Solr, delete documents by query (by the field that contains
> document source repository). We use deleteByQuery and commit SolrJ operations.
> - At this point Solr core have 0 documents (but 4.500 max documents,
> important!!!)
> - Now we add to Solr the new version of source documents (4000). Remember
> that documents don't have unique identifiers, supose that unique items are
> 3000. So when add operation finish (after commit sended) Solr index must have
> 3.000 unique items.
>
> But the result isn't 3.000 unique items, we obtains a random results: 3000,
> 2980, 2976, etc. It's a serious problem because we lost documents.
> We have a workaround. At these operations just after delete operation, we
> send an optimization to Solr (maxDocuments are updated). After this, we send
> new documents. By this way the result is always fine.
> In our tests, we can see that this issue is only when the new documents
> overwrites documents that existed in solr.
> Thanks!!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
