Oh, I forgot Erick's mention of the logs: there's nothing unusual in
INFO level, the update request just gets mentioned. No exception. I
reran it with the DEBUG level, but most of the log was related to jetty.
Here's a line I noticed though:
org.apache.solr.servlet.HttpSolrCall; Closing out SolrRequest:
{wt=json&commit=true&update.chain=dedupe}
The update.chain parameter wasn't part of the original request, and
"dedupe" looks suspicious to me. Perhaps should I investigate further there?
Thanks,
John.
On 08/10/15 08:25, John Smith wrote:
> 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.
>>>>
>
