lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-8903) Move SolrJ DateUtil to Extraction module as ExtractionDateUtil
Date Fri, 25 Mar 2016 02:49:25 GMT

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message