lucene-solr-dev mailing list archives

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


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:
>             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.

View raw message