[jira] [Comment Edited] (SOLR-12591) Ensure ParseDateFieldUpdateProcessorFactory can be used instead of ExtractionDateUtil
[
https://issues.apache.org/jira/browse/SOLR-12591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577109#comment-16577109
]
Bar Rotstein edited comment on SOLR-12591 at 8/11/18 9:59 AM:
--
There is another small detail that I am not sure about.
In ExtractionDateUtil the date is added to the document with type Instance,
while the URP adds the date as a Date type.
The toString() method in each type slightly differ.
Is it OK to save the parsed fields as a Date, even though the XML returned by
them is different? (since ExtractionDateUtil saves a String representation of
Instant?)
Perhaps this could be addressed in
[SOLR-12593|https://issues.apache.org/jira/browse/SOLR-12593], where we could
use the .toInstant() method of the Date object in some way,
to mimic the behavior found in SolrContentLoader?
{code:java}
Instant date = ExtractionDateUtil.parseDate(val, dateFormats); // may throw
result = date.toString();//ISO format
{code}
was (Author: brot):
There is another small detail that I am not sure about.
In DateExtractionUtil the date is added to the document with type Instance,
while the URP adds the date as a Date type.
The toString() method in each type slightly differ.
Is it OK to save the parsed fields as a Date, even though the XML returned by
them is different? (since DateExtractionUtil saves a String representation of
Instant?)
Perhaps this could be addressed in
[SOLR-12593|https://issues.apache.org/jira/browse/SOLR-12593], where we could
use the .toInstant() method of the Date object in some way,
to mimic the behavior found in SolrContentLoader?
{code:java}
Instant date = ExtractionDateUtil.parseDate(val, dateFormats); // may throw
result = date.toString();//ISO format
{code}
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12591) Ensure ParseDateFieldUpdateProcessorFactory can be used instead of ExtractionDateUtil
[
https://issues.apache.org/jira/browse/SOLR-12591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577109#comment-16577109
]
Bar Rotstein edited comment on SOLR-12591 at 8/11/18 9:58 AM:
--
There is another small detail that I am not sure about.
In DateExtractionUtil the date is added to the document with type Instance,
while the URP adds the date as a Date type.
The toString() method in each type slightly differ.
Is it OK to save the parsed fields as a Date, even though the XML returned by
them is different? (since DateExtractionUtil saves a String representation of
Instant?)
Perhaps this could be addressed in
[SOLR-12593|https://issues.apache.org/jira/browse/SOLR-12593], where we could
use the .toInstant() method of the Date object in some way,
to mimic the behavior found in SolrContentLoader?
{code:java}
Instant date = ExtractionDateUtil.parseDate(val, dateFormats); // may throw
result = date.toString();//ISO format
{code}
was (Author: brot):
There is another small detail that I am not sure about.
In DateExtractionUtil the date is added to the document with type Instance,
while the URP adds the date as a Date type.
The toString() method in each type slightly differ.
Is it OK to save the parsed fields as a Date, even though the XML return by
them is different?
Perhaps this could be addressed in
[SOLR-12593|https://issues.apache.org/jira/browse/SOLR-12593], where we could
use the .toInstant() method of the Date object in some way,
to mimic the behavior found in SolrContentLoader?
{code:java}
Instant date = ExtractionDateUtil.parseDate(val, dateFormats); // may throw
result = date.toString();//ISO format
{code}
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12591) Ensure ParseDateFieldUpdateProcessorFactory can be used instead of ExtractionDateUtil
[ https://issues.apache.org/jira/browse/SOLR-12591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572226#comment-16572226 ] Bar Rotstein edited comment on SOLR-12591 at 8/7/18 7:54 PM: - Oh yes it will be a very interesting experiment. Hopefully I'll have time to get to it this weekend. was (Author: brot): Oh yes it will be a very interesting experiment. Hopefully I'll have time to get to it this wrekend. > 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 (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
