lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Male <gento...@gmail.com>
Subject Re: FieldType refactoring?
Date Sat, 22 Oct 2011 00:58:12 GMT
I really recommend looking at some of the discussion near the end of
LUCENE-2308.  The role of EnumSet and the opinions on its use have been put
forward there.

On Sat, Oct 22, 2011 at 3:32 AM, Adnan Duric <aduric@gmail.com> wrote:

> Fair enough. I'd just like to get some opinions on using EnumSet instead of
> the bit field in the ctor. So instead of having
>
> new FieldType(INDEXED | STORED)
>
> we wrap the options in an EnumSet,
>
> new FieldType(EnumSet.of(INDEXED, STORED))
>
> The obvious advantage is that we don't need to explicitly set the option
> members in FieldType, so no binary logic.
>
>
> Regards,
>
>
> Adnan
>
>
>
> On Thu, Oct 20, 2011 at 9:24 PM, Chris Male <gento0nz@gmail.com> wrote:
>
>> Good question.  I think FieldType should still require an explicit
>> parameter.  If we then want to build a sugar StoredFieldType class, well
>> then thats fine, but FieldType should layout clearly what values can be
>> set.
>>
>>
>> On Fri, Oct 21, 2011 at 2:11 PM, Adnan Duric <aduric@gmail.com> wrote:
>>
>>> That could work, but what happens when the user doesn't want indexing,
>>> ie, indexed = false? I guess the IndexOptions argument could be ignored if
>>> no indexing is taking place, but then we are forcing the user to enter a
>>> dummy parameter.
>>>
>>>
>>> On Thu, Oct 20, 2011 at 8:52 PM, Chris Male <gento0nz@gmail.com> wrote:
>>>
>>>> I really favour sticking to the existing enum and don't think we should
>>>> unravel them into int flags for the reasons already put forward.
>>>>
>>>> Having thought about my original concern, I think its best we don't make
>>>> it an optional argument, we should force users to specify what IndexOptions
>>>> they want explicitly.
>>>>
>>>> On Fri, Oct 21, 2011 at 1:42 PM, Adnan Duric <aduric@gmail.com> wrote:
>>>>
>>>>> We can pass an enum member individually (DOCS_ONLY, DOCS_AND_FREQS...)
>>>>> to the ctor to prevent inconsistencies. This way we would have the same
>>>>> number of extra arguments as splitting them, and no complex pair checking
>>>>> between them.
>>>>>
>>>>>
>>>>> On Thu, Oct 20, 2011 at 6:40 PM, Simon Willnauer <
>>>>> simon.willnauer@googlemail.com> wrote:
>>>>>
>>>>>> On Thu, Oct 20, 2011 at 10:35 PM, Robert Muir <rcmuir@gmail.com>
>>>>>> wrote:
>>>>>> > On Thu, Oct 20, 2011 at 8:16 PM, Michael McCandless
>>>>>> > <lucene@mikemccandless.com> wrote:
>>>>>> >
>>>>>> >> We'd need checking in FT's ctor to catch wrong pairings,
eg you
>>>>>> cannot
>>>>>> >> turn ont POSITIONS unless you also turn on FREQS, and at
least DOCS
>>>>>> >> must be set if INDEXED is set.
>>>>>> >>
>>>>>> >
>>>>>> > What is the problem with the enum? it prevents these
>>>>>> inconsistencies...
>>>>>> +1 to stick to enums here!
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > lucidimagination.com
>>>>>> >
>>>>>> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Chris Male | Software Developer | DutchWorks | www.dutchworks.nl
>>>>
>>>
>>>
>>
>>
>> --
>> Chris Male | Software Developer | DutchWorks | www.dutchworks.nl
>>
>
>


-- 
Chris Male | Software Developer | DutchWorks | www.dutchworks.nl

Mime
View raw message