lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adnan Duric <adu...@gmail.com>
Subject Re: FieldType refactoring?
Date Sat, 22 Oct 2011 01:21:57 GMT
I've read the discussion and EnumSet was mentioned but nobody really had an
opinion on it. I guess I can put forward a patch with EnumSet and then wait
and see.

On Fri, Oct 21, 2011 at 8:58 PM, Chris Male <gento0nz@gmail.com> wrote:

> 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