lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Schema Change: Int -> String
Date Thu, 06 Jun 2013 05:58:06 GMT
On 6/5/2013 11:25 PM, TwoFirst TwoLast wrote:
> 1) If I change one field's type in my schema, will that cause problems with
> the index or searching?  My data is pulled in chunks off of a mysql server
> so one field in the currently indexed data is simply an "int" type field in
> solr.  I would like to change this to a string moving forward, but still
> expect to search across the int/string field.  Will this be ok?
> 2) My motivation for #1 is that I have thousands of records that are
> exactly the same in mysql aside from a user_id column.  Prior to inserting
> into mysql I am thinking that I can concatenate the user_ids together into
> a space separated string and let solr just parse the string.  So the
> database and my data import handler would change a bit.
> 3) If #2 is an appropriate approach, will a solr.TextField with
> a solr.WhitespaceTokenizerFactory be an ok way to approach this?  This does
> produce words where I would expect integers. I tried using a
> solr.TrieIntField with the solr.WhitespaceTokenizerFactory, but it throws
> an error.

If you change the field type, you have to completely reindex or Solr
will not work correctly.  This is true of most changes in schema.xml.

A field that was indexed as an int will not work correctly if you later
tell Solr that the field is a string.  The underlying Lucene index is
schema-less and has no idea what high-level data type each field is
using.  Solr reads and writes a particular data representation on each
field according to schema.xml.

Using an analysis chain (tokenizers and filters) is only supported on a
TextField.  It will not work on any other type, including StrField and


View raw message