Thanks for the prompt response. Comments below ... [EMAIL PROTECTED] wrote on 05/31/2007 10:55:57 AM:
> On 5/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I am trying to override the tokenized attribute of a single FieldType from > > the field attribute in schema.xml, but it doesn't seem to work > > The "tokenized" attribute is not settable from the schema, and there > is no reason I can think of why this would be useful rather than > confusing. > You say the "tokenized" attribute is not settable from the schema, but the output from IndexSchema.readConfig shows that the properties are indeed read, and the resulting SchemaField object retains these properties: are they then ignored? > "untokenized" means don't use the analyzer. If you don't want an > analyzer, then use the "string" type. > This is true only in the simplest of cases. An analyzer can do far more than tokenize: it can stem, change to lower case, etc. What if you want one or more of these things to happen, but you don't want tokenization? In this particular case I want to be able to make exact matches on the entire field, so that a search for "+termExact:pain" (remember that my searches are case insensitive, thanks to my analyzer (and regardless of tokenization)) will return _only_ the document in which the termExact field contains the single word "Pain" or "pain", and not "Back Pain", etc. > > PS: Yes, I know I could use solr.StrField for those fields > > Could you provide a use-case why you don't want to use StrField > (normally type "string" in the schema)? What is the external behaviour > you are looking for? > Part of the answer to this question is in the last paragraph, but perhaps you want to know why I would like to consolidate all field properties to the field element. The reason for this is that the schema is read by another class to give access to field properties and more outside the Solr context. -- Robert
