I have noticed that when I write a doc with an id that already exists, it creates a new revision with the only the fields from the second write. I guess there is a REST API in the latest solr version which updates only selected fields.
In my opinion, merge should be creating a doc which is a union of the fields assuming the fields are conforming to the schema of the output index. ~ Sourajit On Sun, Jun 9, 2013 at 12:06 AM, Mark Miller <markrmil...@gmail.com> wrote: > > On Jun 8, 2013, at 12:52 PM, Jamie Johnson <jej2...@gmail.com> wrote: > > > When merging through the core admin ( > > http://wiki.apache.org/solr/MergingSolrIndexes) what is the policy for > > conflicts during the merge? So for instance if I am merging core 1 and > > core 2 into core 0 (first example), what happens if core 1 and core 2 > both > > have a document with the same key, say core 1 has a newer version of core > > 2? Does the merge fail, does the newer document remain? > > You end up with both documents, both with that ID - not generally a > situation you want to end up in. You need to ensure unique id's in the > input data or replace the index rather than merging into it. > > > > > Also if using the srcCore method if a document with key 1 is written > while > > an index also with key 1 is being merged what happens? > > It depends on the order I think - if the doc is written after the merge > and it's an update, it will update the doc that was just merged in. If the > merge comes second, you have the doc twice and it's a problem. > > - Mark