Sorry the delay on my reply. I have tried to use the Documents screen for
executing my update request processor (with JSON), but it needs the
document Id to be specified. So, this is not a good solution as I need to
update all indexed documents... I will try on importEnd event. Any other
idea?
On
Roxana - please share your full configuration (minus passwords of course) so we
can all see what the dilemma is. I can’t make sense of what you’re trying and
why you’re trying it that way rather than intra-update-script-analysis.
Erik
> On Oct 23, 2015, at 2:49 AM, Roxana Danger
>
Hi Alexandre,
No, this is what is missing... I assume I can select the docs with a query
(e.g. *:*, in the content.stream?), but I haven't found which parameter is
the right one to use...
Thanks,
Roxana
On 22 October 2015 at 18:27, Alexandre Rafalovitch
wrote:
> You need to tell the second ca
You need to tell the second call which documents to update. Are you doing
that?
There may also be a wrinkle in the URP order, but let's get the first step
working first.
On 22 Oct 2015 12:59 pm, "Roxana Danger"
wrote:
> yes, it's working now... but I can not use the updateprocessor chain. I
> ne
Yes, it works (now, not sure when though). I just adjusted the
TestContentStreamDataSource test case, see patch pasted below, that passes.
Note that the solrconfig file has a mistake in that the attribute ‘key’ isn’t
correct - should be ‘name’
(this was tested on trunk via IntelliJ, just FYI
yes, it's working now... but I can not use the updateprocessor chain. I
need to use first the DIH and then use UPR, but I am not having luck in
updating my docs with the URL:
http://localhost:8983/solr/reed_jobs/update/jtdetails?commit=true
Do you manage to use an updateProcessor chain after use t
Yes, it arrives there...
On 22 October 2015 at 17:32, Erik Hatcher wrote:
> Setting “update.chain” in the DataImportHandler handler defined in
> solrconfig.xml should allow you to specify which update chain is used. Can
> you confirm that works, Shawn?
>
> This is from DataImportHandler.java:
On 10/22/2015 10:32 AM, Erik Hatcher wrote:
> Setting “update.chain” in the DataImportHandler handler defined in
> solrconfig.xml should allow you to specify which update chain is used. Can
> you confirm that works, Shawn?
I tried this a couple of years ago without luck. Does it work now?
htt
Setting “update.chain” in the DataImportHandler handler defined in
solrconfig.xml should allow you to specify which update chain is used. Can you
confirm that works, Shawn?
This is from DataImportHandler.java:
UpdateRequestProcessorChain processorChain =
req.getCore().getUpdateProces
On 10/22/2015 10:09 AM, Roxana Danger wrote:
> The DIH is executed correctly and the tokenized representation is obtained
> correctly, but the URP chain is not executed with the call:
> http://localhost:8983/solr/reed_jobs/update/details?commit=true
> Isn't it the correct URL? is there any paramete
Hi Alexandre,
The DIH is executed correctly and the tokenized representation is obtained
correctly, but the URP chain is not executed with the call:
http://localhost:8983/solr/reed_jobs/update/details?commit=true
Isn't it the correct URL? is there any parameter missing?
Best,
Roxana
On 22 Octobe
Well, I guess I imagined three steps:
1) Run DIH
2) Get the tokenized representation for each document using facets or
other approaches
3) Submit document partial-update request with additional custom
processing through URP
Your example seems to be skipping step 2, so the URP chain does not
know w
It is still not clear what problem you are really trying to solve. This is
what we call an XY problem - you are focusing on your intended solution but
not describing the original, underlying problem, the application itself.
IOW, there may be a much more appropriate solution for us to suggest if
onl
Hi Erik,
Thanks for the links, but the analyzers are called correctly. The problem
is that I need to get access to the whole set of terms through a searcher,
but the request searcher cannot retrieve any terms because the commit
method has not been called already.
My idea behind this is avoid two
Hi Alex,
My idea behind this is avoid two calls: first, the importer and after the
updater. As there is an update processor chain than can be used after the
DIH, I thorough it was possible to get a real-time updater.
So, I am getting your advice and dividing the process in different steps. I
have
Roxana -
What is the purpose of doing this? (that’ll help guide the best approach)
It can be quite handy to get the terms from analysis into a field as stored
values and to separate terms into separate fields and such. Here’s a
presentation where I detailed an update script trick that accompl
You are doing things out of order. It's DIH, URP, then indexer. Any
attempt to subvert that order for the record being indexed will end in
problems.
Have you considered doing a dual path? Index, then update. Of course,
your fields all need to be stored for that.
Also, perhaps you need to rethink
Dear Mikhail,
Thank you very much for your advice. I have tried, but the realTimeSearcher
didn't help...
This may looks very silly but: can a commit be called with
RunUpdateProcessorFactory? Can I use it twice in a
updateRequestProcessorChain?
Thank you very much again,
Roana
On 22 October 2015
Hello Roxana,
I feel it's almost impossible. I can only suggest to commit to make new
terms visible.
There is SolrCore.getRealtimeSearcher() but I never understand what it
does.
On Thu, Oct 22, 2015 at 1:20 PM, Roxana Danger <
roxana.dan...@reedonline.co.uk> wrote:
> Hello,
>
> I would like to c
19 matches
Mail list logo
