For this I prefer TemplateTransformer to RegexTransformer - its not a
regex, just a pattern, and so should be more efficient to use
TemplateTransformer. A script will also work, of course.
On Tue, Jan 27, 2015 at 5:54 PM, Alexandre Rafalovitch
wrote:
> On 27 January 2015 at 17:47, Carl Roberts
On 27 January 2015 at 17:47, Carl Roberts wrote:
> commonField="false" regex=":" replaceWith=" "/>
Yes, that works because the transformer copies it, not the
EntityProcessor. So, no conflict on xpath.
Regards,
Alex.
Sign up for my Solr resources newsletter at http://www.solr-start.com/
You are right - I just checked and now the other field
(vulnerable-software) that is using the same xpath has blank values.
BTW - It looks like this also works:
commonField="false" regex=":" replaceWith=" "/>
Here are the results for one row in json:
"responseHeader":{
"status":0,
One xpath per field definition. You had two fields for the same xpath.
If they were the same value, the best bet would be to deal with it via
copyField in the schema.
No idea why regex thing makes a difference, are you sure the other
field is also still being indexed?
Regards,
Alex.
Sign
Well - I got this to work. Noticed that when log4j is enabled
product-info was in the import as product-info=[], so I then played with
the field and got this definition to work in the rss-data-config.xml file:
xpath="/nvd/entry/vulnerable-software-list/product" commonField="false"
regex=":" r
Hi,
I have tried to reindex to add a new field named product-info and no
matter what I do, I cannot get the new field to appear in the index
after import via DIH.
Here is the rss-data-config.xml configuration (field product-info is the
new field I added):
readTimeout="3"/>
