[
https://issues.apache.org/jira/browse/SOLR-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-8903.
--------------------------------
Resolution: Fixed
Thanks for the review Steve! Maybe I should start generating patches from the
command line. FWIW looking at the patch I do see the leading {{solr/}} but I
know many patches I've seen out there have some sort of nominal a/ or b/ or
something like that in front.
> Move SolrJ DateUtil to Extraction module as ExtractionDateUtil
> --------------------------------------------------------------
>
> Key: SOLR-8903
> URL: https://issues.apache.org/jira/browse/SOLR-8903
> Project: Solr
> Issue Type: Task
> Components: SolrJ
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.0
>
> Attachments: SOLR_8903.patch, SOLR_8903_DateUtil_deprecate.patch
>
>
> SolrJ doesn't need a DateUtil class, particularly since we're on Java 8 and
> can simply use {{new Date(Instant.parse(d).toEpochMilli());}} for parsing and
> {{DateTimeFormatter.ISO_INSTANT.format(d.toInstant())}} for formatting. Yes,
> they are threadsafe. I propose that we deprecate DateUtil from SolrJ, or
> perhaps outright remove it from SolrJ for Solr 6. The only SolrJ calls into
> this class are to essentially use it to format or parse in the ISO standard
> format.
> I also think we should move it to the "extraction" (SolrCell) module and name
> it something like ExtractionDateUtil. See, this class has a parse method
> taking a list of formats, and there's a static list of them taken from
> HttpClient's DateUtil. DateUtil's original commit was SOLR-284 to be used by
> SolrCell, and SolrCell wants this feature. So I think it should move there.
> There are a few other uses:
> * Morphlines uses it, but morphlines depends on the extraction module so it
> could just as well access it if we move it there.
> * The ValueAugmenterFactory (a doc transformer). I really doubt whoever
> added it realized that DateUtil.parseDate would try a bunch of formats
> instead of only supporting the ISO canonical format. So I think we should
> just remove this reference.
> * DateFormatUtil.parseMathLenient falls back on this, and this method is in
> turn called by just one caller -- DateValueSourceParser, registered as
> {{ms}}. I don't think we need leniency in use of this function query; values
> given to ms should be computer generated in the ISO format.
> ----
> edit: added ms().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
