Look for the DedupUpdateProcessor in an update chain.
that is there, but commented out IIRC in the techproducts sample
configs.
Perhaps you uncommented it to use your own update processors, but didn't
remove that component?
On Thu, Oct 8, 2015, at 07:38 AM, John Smith wrote:
> 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.
> >>>>
> >
>
