[
https://issues.apache.org/jira/browse/SOLR-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4538:
---------------------------
Attachment: SOLR-4538.patch
bq. I just changed it to 128 for date fields.
I don't like the idea of kicking the can from 32 chars to 128 chars ...
particularly since we've already seen from the original report of this issue
how simple truncation can lead to silently incorrect results instead of any
clear and obvious error message.
it seems simple enough to just grow the buffer if the input is long then
expected -- it doesn't add any overhead to the common case of "normal" date
(math) strings.
New patch includes:
* my previous tests
* yonik's test
* yonik's change to default the buffer size to 128 if it's a DATE field
* a change to grow the buffer if it's not long enough
* a test demonstrating date math strings longer then 128 chars
> DateMathParser doesn't work correctly.
> --------------------------------------
>
> Key: SOLR-4538
> URL: https://issues.apache.org/jira/browse/SOLR-4538
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 4.1
> Reporter: Minoru Osuka
> Attachments: SOLR-4538.patch, SOLR-4538.patch, SOLR-4538_test.patch
>
>
> DateMathParser doesn't work correctly.
> http://lucene.apache.org/solr/4_1_0/solr-core/org/apache/solr/util/DateMathParser.html
> fq=last_modified:"2013-03-08T00:46:15Z/DAY+6MONTHS+3DAYS"
> expected; last_modified:2013-09-11T00:00:00Z
> actual; last_modified:2013-09-08T00:00:00Z
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
