lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Male <>
Subject Re: FieldType refactoring?
Date Thu, 20 Oct 2011 02:35:09 GMT
On Thu, Oct 20, 2011 at 5:23 AM, Adnan Duric <> wrote:

> Hi Chris,
> Thanks for the feedback. If you want to create an issue in JIRA, I'd be
> happy to contribute a patch to convert the FieldType constructor to bit
> flags. How would you want to handle the IndexOptions enum?

That's a good question.  Forcing it to be a compulsory constructor argument
is a little messy, but so is having two constructors to support defaults.
 This is the kind of problem that we discussed in LUCENE-2308 as Mike
mentioned.  Feel free to open the issue yourself :) and attach a patch which
deals with it in a way you feel happy with.  We can all then review it and

> Regards,
> Adnan
> On Tue, Oct 18, 2011 at 9:03 PM, Chris Male <> wrote:
>> Hi,
>> I agree with pretty much everything Mike says. When I get round to it I
>> will make a patch for converting FieldType over to int bit flags.
>> I also like the idea of having strongly typed sugar classes for the
>> various FieldTypes.
>> Just a couple of things:
>> This means that the IndexableField classes such as TextField, NumericField
>>> and the like would not be needed at all, and would be replaced by FieldType
>>> classes like TextType and NumericType for example; with only one constructor
>>> instead of several. Also, at that point, Field must be declared final.
>> TextField doesn't really serve any purpose other than typing its true, but
>> NumericField and BinaryField do.  They control what values can be used and
>> how they are converted to a tokenStream (well, BinaryField will do this in
>> the future).  So we can't remove them.
>>>  > This way, the FieldType class is no longer needed, the IndexableField
>>>> type
>>>> > classes don't need to mutate anything, and, in the end, are
>>>> instantiated the
>>>> > same way.
>> Aren't we always going to need FieldType? Sure we can make some
>> assumptions about the likely combination of properties that will be set, but
>> we shouldn't box ourselves in.  Today FieldType consists of just boolean
>> parameters, but there has also been discussion around moving other things
>> like NumericField DataType and IndexDocValues properties there too.  I like
>> having an easy way for users to do common scenarios, but I also feel one of
>> the motivations for the changes we made to Field/FieldType recently is to
>> give people greater freedom.
>> Cheers!
>> --
>> Chris Male | Software Developer | DutchWorks |

Chris Male | Software Developer | DutchWorks |

View raw message