[jira] [Commented] (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=16597486#comment-16597486 ] ASF subversion and git services commented on SOLR-12591: Commit 4096decd8f6e496d2307d4c1c4eccefbfcd8f74a in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4096dec ] SOLR-12591: ParseDateField URP should default to "en_US" locale (not ROOT) which is implied by common formats. Should fix Java 9,10,11 test fails; Java 8 continues to work. > 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: Major > Fix For: master (8.0) > > Attachments: SOLR-12591.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > 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. Additionally > the default configSet's configuration of this URP should be expanded to > include the patterns parsed by the extract contrib. > Once this issue is complete, it should be appropriate to gut date time > parsing out of the "extraction" contrib module – a separate issue (see > SOLR-12593). -- 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] [Commented] (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=16596677#comment-16596677 ] ASF subversion and git services commented on SOLR-12591: Commit 18874a6e36b1930bc7437ee3f1095912b1d20a95 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=18874a6 ] SOLR-12591: Expand default configSet's date patterns to subsume those of extract contrib > 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) > > Attachments: SOLR-12591.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > 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] [Commented] (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=16582962#comment-16582962 ] ASF subversion and git services commented on SOLR-12591: Commit a661ebc6dfc0aa00161bde402edb7171d390f076 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a661ebc ] SOLR-12591: Avoid JDK 9 bug with certain timezones like AKDT; test with EDT. Also standardized on single 'z' in the test patterns, which is equivalent to triple. > 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) > > Attachments: SOLR-12591.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > 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] [Commented] (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=16580694#comment-16580694 ] ASF subversion and git services commented on SOLR-12591: Commit ec01cc981c0ff221c79014f3665fd21c227d5651 in lucene-solr's branch refs/heads/master from [~barrotsteindev] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ec01cc9 ] SOLR-12591: ParseDateFieldUpdateProcessorFactory: Use "lenient" and strip surrounding quotes. More tests, ported from "extract" contrib stuff. > 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) > > Attachments: SOLR-12591.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > 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] [Commented] (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=16580654#comment-16580654
]
Lucene/Solr QA commented on SOLR-12591:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 77m 20s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 87m 58s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.IndexSizeTriggerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12591 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12935608/SOLR-12591.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 0d89ff2 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/162/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/162/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/162/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> 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)
>
> Attachments: SOLR-12591.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (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=16577227#comment-16577227 ] Bar Rotstein commented on SOLR-12591: - Hey [~dsmiley], I just filed a PR. Would be lovely if you could take a look at it. Thanks in advance. > 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) > > Time Spent: 20m > Remaining Estimate: 0h > > 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] [Commented] (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=16577206#comment-16577206 ] Bar Rotstein commented on SOLR-12591: - Alright it seems like the way forward is to currently put the Date into the document instead of the String. One thing that should be documented is the different Date String format that will be returned due to this change. Though this probably belongs in [SOLR-12593|https://issues.apache.org/jira/browse/SOLR-12593] > 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] [Commented] (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=16577197#comment-16577197
]
David Smiley commented on SOLR-12591:
-
{{org.apache.solr.handler.extraction.SolrContentHandler#transformValue}} is
placing the ISO instant format _String_ back onto the document, not an Instance
object. You're correct the URP puts a Date object on the doc; that's what it
_should_ do (avoids further parsing). It will ultimately find its way into
{{DatePointField.createField}} and used directly. Again after SOLR-12593, the
SolrContentHandler will be doing no date processing whatsoever. There will be
only one place where a configurable list of date/time patterns are processed --
this URP. Someone using SolrContentHandler will be expected to use the URP.
In some future issue that I don't think has been filed, it would be nice to use
Instant basically everywhere and avoid Date.
> 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] [Commented] (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=16577145#comment-16577145 ] Bar Rotstein commented on SOLR-12591: - After thinking about this for a bit, it seems to me as if having a single point of date extraction as well as a single string format(Date#toString) for dates in Solr would be for the better. Although, I must admit, I am fairly new to this. Perhaps someone with more experience could provide his opinion. [~dsmiley], WDYT? > 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] [Commented] (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=16577109#comment-16577109
]
Bar Rotstein commented on SOLR-12591:
-
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] [Commented] (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=16576661#comment-16576661 ] David Smiley commented on SOLR-12591: - "lenient" boolean can be global to the URP (spanning formats). This is consistent with the existing default/override timezone setting, and is rather simple. I don't think the URP should try and be some public API. I don't think there's a need for that in Solr. We can change our mind in the future if a use-case presents itself. > 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] [Commented] (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=16576607#comment-16576607 ] Bar Rotstein commented on SOLR-12591: - Another question that has come to mind, is whether the URP should mimic DateExtractionUtil, and provide a public API to build a DateFormatter, or whether the formatters used should be strictly be only the ones provided in the configuration? > 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] [Commented] (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=16576484#comment-16576484 ] Bar Rotstein commented on SOLR-12591: - I have been trying to decide where the lenient configuration should be placed. Would the mode be specified globally, or separately for each format? WDYT? > 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] [Commented] (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=16576477#comment-16576477
]
Bar Rotstein commented on SOLR-12591:
-
{quote}I'm really wondering if lenient is true, then will "Z" pattern work with
an older config{quote}
I tried running the tests under ParsingFieldUpdateProcessorsTest with parsers
set to SMART and LENIENT modes, and both test cases produced similar results.
Even under these two modes the parser cannot handle the "Z" using the old
configuration.
> 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] [Commented] (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=16572226#comment-16572226 ] Bar Rotstein commented on SOLR-12591: - 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
[jira] [Commented] (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=16572160#comment-16572160 ] David Smiley commented on SOLR-12591: - Oh awesome; I'm glad you're interested in it Bar. I have not started working on it. I think in this issue we will almost certainly need to add a "lenient" boolean flag to ParseDateFieldUpdateProcessorFactory. Hmmm; I'm really wondering if lenient is true, then will "Z" pattern work with an older config (someone who didn't update config even though our upgrade notes tell them to)? Interesting experiment to do. > 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] [Commented] (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=16572148#comment-16572148 ] Bar Rotstein commented on SOLR-12591: - Is this ticket up for grabs, or are you working on it since it is assigned to you [~dsmiley]? > 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
