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
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
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
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
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
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
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
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,
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
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
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
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
12 matches
Mail list logo
