: termfrequency : 2008-04-24T09:03:53Z11076 : 2008-04-24T09:03:55Z10036 i'm assuming "11076" and "10036" are the term frequencies?
Yes - the cut-n-paste didn't do a good job separating the columns : This now seems to be something different than SOLR-470 and SOLR-544 : since the format seems to be accepted at indexing, and is consistent in : the index, but is still not accepted at query time. if i'm understanding correctly the "same format" you picked was no milliseconds at all -- this is exactly what triggers SOLR-470 at the moment. To avoid that you need to be consistent in using milliseconds. Here is what I did. First Try: * date column required with NOW as default value. * 2 files uploaded into the index. One had the field specified with no millis, and the other omitted the column and therefore was triggering the default value of NOW. --> got the exception, researched and found SOLR-470, SOLR-544 Second Try: * same date column setup * 2 files uploaded into the index. Updated the file with the timestamps to be 3 digit millis to 'match' what NOW was supposed to be doing. I left the other file alone. --> got the exception.. check data in Luke to confirm it was all 3 digit millis and it was. Third Try: * removed default value from the schema * added 3 digit millis to the file that didn't have the date specified --> exception went away, everything worked great. Observation: If I used NOW as a default value, whether I used no millis or 3 digit millis in the files I uploaded into the index, I saw the exception at query time when I uploaded a file that triggered the default value. ... so I gave up on using NOW for now as the default value. I hope that helps clarify what happened. Thanks, Brian
