David Smiley commented on SOLR-12591:

{{org.apache.solr.handler.extraction.SolrContentHandler#transformValue}} is 
placing the ISO instant format _String_ back onto the document, not an Instance 
object.  You're correct the URP puts a Date object on the doc; that's what it 
_should_ do (avoids further parsing).  It will ultimately find its way into 
{{DatePointField.createField}} and used directly.  Again after SOLR-12593, the 
SolrContentHandler will be doing no date processing whatsoever.  There will be 
only one place where a configurable list of date/time patterns are processed -- 
this URP.  Someone using SolrContentHandler will be expected to use the URP.

In some future issue that I don't think has been filed, it would be nice to use 
Instant basically everywhere and avoid Date.

> Ensure ParseDateFieldUpdateProcessorFactory can be used instead of 
> ExtractionDateUtil
> -------------------------------------------------------------------------------------
>                 Key: SOLR-12591
>                 URL: https://issues.apache.org/jira/browse/SOLR-12591
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>             Fix For: master (8.0)
> ParseDateFieldUpdateProcessorFactory should ideally be able to handle the 
> cases that ExtractionDateUtil does in the "extraction" contrib module.  Tests 
> should be added, ported from patches in SOLR-12561 that enhance 
> TestExtractionDateUtil to similarly ensure the URP is tested.  I think in 
> this issue, I should switch out Joda time for java.time as well (though leave 
> the complete removal for SOLR-12586) if it any changes are actually necessary 
> – they probably will be.
> Once this issue is complete, it should be appropriate to gut date time 
> parsing out of the "extraction" contrib module – a separate issue. 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to