[
https://issues.apache.org/jira/browse/SOLR-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-8903:
-------------------------------
Attachment: SOLR_8903.patch
Updated patch which moves DateUtil to the extraction module as
ExtractionDateUtil. It depends on SOLR-8904 in that some call sites into
DateUtil are updated in that patch, not this one now. DateMathParser is not
referred to at all. I also added some tests, ported from DateMathParserTest.
Suggested CHANGES.txt:
{noformat}
(in upgrading)
* SolrJ no longer includes DateUtil. If for some reason you need to format or
parse dates, simply use Instant.format() and Instant.parse().
(in other)
* SOLR-8904: DateUtil in SolrJ moved to the extraction contrib as
ExtractionDateUtil. Obsolete methods were removed.
{noformat}
> 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: [email protected]
For additional commands, e-mail: [email protected]
