lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Johnson <>
Subject Re: SOLR-470 & default value in schema with NOW (update)
Date Mon, 28 Apr 2008 05:02:42 GMT
: 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

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.

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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message