On Oct 17, 2007, at 1:36 PM, Thiago Jackiw wrote:
Yeah unfortunately I can't change that field, it has to be kept as
integer. And also I don't think it would make any difference because
when you eval the string "08817" or the number 08817 they both get the
same error.
I still don't understand why you need to keep that as an integer.
You're obviously sending it in as a String (or it wouldn't have a
leading 0 on it). And when you get it back as an integer it'll be
8817, not 08817 so to redisplay it you'd surely want to pad it
again. Could you elaborate on why you want to store this as an
integer? Keep in mind that you could have a zip code field for
display purposes and one for sorting or ranges using a copyField.
Any objections to changing Solr's Ruby response writer to prefixing
integers with "0d"? That'll do the trick:
irb(main):002:0> eval('0d08')
=> 8
That actually makes good sense to me. I've started doing this
locally and once I've created the test case infrastructure for this
I'll commit unless there are issues I've not considered.
Erik
