Hi Allessandro,
In the example I set the value to 1, but it's actually incremented in
the code, so with time it should go up. You're right though, I could use
an inc update instead.
John
On 08/10/15 16:45, Alessandro Benedetti wrote:
> Not related to the deletion problem, only as a curiosity fo
Not related to the deletion problem, only as a curiosity for your use case :
1
Have i misunderstood your use case, or you should use :
inc
Increments a numeric value by a specific amount.
Must be specified as a single numeric value.
Basically overtime you click, you always set the value for t
Well, every day we update a lot of documents (usually several millions)
so the DIH is a good fit.
Calling the update chain would make sense there: after all a data import
is just a batch update. Otherwise, the same operations would have to be
made upfront, possibly in another environment and/or la
You can either specify the update chain via an update.chain request
parameter, or you can configure a new request parameter with its own URL
and separate update.chain value.
I have no idea how you would then reference that in the DIH - I've never
really used it.
Upayavira
On Thu, Oct 8, 2015, a
After some further investigation, for those interested: the
SignatureUpdateProcessorFactory fields were somehow mis-configured (I
guess copied over from another collection). The initial import had been
made using a data import handler: I suppose the update chain isn't
called in this process and no
Yay!
On Thu, Oct 8, 2015, at 08:38 AM, John Smith wrote:
> Yes indeed, the update chain had been activated... I commented it out
> again and the problem vanished.
>
> Good job, thanks Erick and Upayavira!
> John
>
>
> On 08/10/15 08:58, Upayavira wrote:
> > Look for the DedupUpdateProcessor in
Yes indeed, the update chain had been activated... I commented it out
again and the problem vanished.
Good job, thanks Erick and Upayavira!
John
On 08/10/15 08:58, Upayavira wrote:
> Look for the DedupUpdateProcessor in an update chain.
>
> that is there, but commented out IIRC in the techproduc
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
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 SolrRe
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:
101084385_Sebago_ sebago s
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
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 lo
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:
abc
1
1.05
(Clicks is an int field; Boost is a float field, it's updated to reflect
the change in popular
13 matches
Mail list logo