The ids are all different: they're unique numbers followed by a couple of keywords. I've made a test with a small collection of 10 documents to make sure I can manage them manually: all ids are confirmed as different.
I also dumped the exact command, here's one example: <add><doc><field name="Id">101084385_Sebago_ sebago shoes</field><field name="Clicks" update="set">1</field><field name="Boost" update="set">1.8701925463775</field></doc></add> It's sent as the body of a POST request to http://127.0.0.1:8080/solr/ato_test/update?wt=json&commit=true, with a Content-Type: text/xml header. I still noted the consistent loss of another document with the update above. John On 08/10/15 00:38, Upayavira wrote: > What ID are you using? Are you possibly using the same ID field for > both, so the second document you visit causes the first to be > overwritten? > > Upayavira > > On Wed, Oct 7, 2015, at 06:38 PM, Erick Erickson wrote: >> This certainly should not be happening. I'd >> take a careful look at what you actually send. >> My _guess_ is that you're not sending the update >> command you think you are.... >> >> As a test you could just curl (or use post.jar) to >> send these types of commands up individually. >> >> Perhaps looking at the solr log would help too... >> >> Best, >> Erick >> >> On Wed, Oct 7, 2015 at 6:32 AM, John Smith <solr-u...@remailme.net> >> wrote: >>> Hi, >>> >>> I'm bumping on the following problem with update XML messages. The idea >>> is to record the number of clicks for a document: each time, a message >>> is sent to .../update such as this one: >>> >>> <add> >>> <doc> >>> <field name="Id">abc</field> >>> <field name="Clicks" update="set">1</field> >>> <field name="Boost" update="set">1.05</field> >>> </doc> >>> </add> >>> >>> (Clicks is an int field; Boost is a float field, it's updated to reflect >>> the change in popularity using a formula based on the number of clicks). >>> >>> At the moment in the dev environment, changes are committed immediately. >>> >>> >>> When a document is updated, the changes are indeed reflected in the >>> search results. If I click on the same document again, all goes well. >>> But when I click on an other document, the latter gets updated as >>> expected but the former is plainly deleted. It can no longer be found >>> and the admin core Overview page counts 1 document less. If I click on a >>> 3rd document, so goes the 2nd one. >>> >>> >>> The schema is the default one amended to remove unneeded fields and add >>> new ones, nothing fancy. All fields are stored="true" and there's no >>> <copyField>. I've tried versions 5.2.1 & 5.3.1 in standalone mode, with >>> the same outcome. It looks like a bug to me but I might have overlooked >>> something? This is my first attempt at atomic updates. >>> >>> Thanks, >>> John. >>>
