lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (SOLR-750) DateField.parseMath doesn't handle non-existent Z
Date Wed, 03 Sep 2008 06:35:44 GMT

     [ https://issues.apache.org/jira/browse/SOLR-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man resolved SOLR-750.
---------------------------

    Resolution: Invalid

The exception is correct -- that is an invalid date string (as far as being input to parseMath,
toInternal, or DateField.getAnalyzer().tokenStream is concerned)

The SOLR-540 patch is doing something it shouldn't be (which seems likely since it makes absolutely
no sense to try and highlight a DateField) *and/or* the Highlighter has a bug (why is getBestTextFragments
passing an indexed token to an Analzyer?)

Either way: parseMath is doing the right thing.

> DateField.parseMath doesn't handle non-existent Z
> -------------------------------------------------
>
>                 Key: SOLR-750
>                 URL: https://issues.apache.org/jira/browse/SOLR-750
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 1.3
>            Reporter: David Smiley
>            Priority: Minor
>         Attachments: SOLR-750_DateField_no_Z.patch
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> I've run into situations when trying to use SOLR-540 (wildcard highlight spec) such that
if attempts to highlight a date field, I get a stack trace from DateField.parseMath puking
because there isn't a "Z" at the end of an otherwise good date-time string.  It was very easy
to fix the code to make it react gracefully to no Z.  Attached is the patch.  This bug isn't
really related to SOLR-540 so please apply it without waiting for 540.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message