[
https://issues.apache.org/jira/browse/SOLR-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-8903:
-------------------------------
Description:
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().
was:
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 couple 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.
> 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
>
> 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]
