Mailing List Archive

StanardFilter Question : https://issues.apache.org/jira/browse/LUCENE-8356
According to this jira ticket, where else is StandardFilter included in
Lucene 8.1.1?

and why is it a no-op now in Lucene 8.1.1?

I wish the tickets were a bit more explicit and suggest what to use
instead for deprecated versions like in version 7.5.0 or why it became
no-op in version 8.1.1?

this will make easy when ugrading to later versions.

Thanks


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: StanardFilter Question : https://issues.apache.org/jira/browse/LUCENE-8356 [ In reply to ]
I did the research on this one because it confused me as well, but it
seems it was a no-op. So the replacement is just to remove it from the
filter chain.

We have a backwards compatibility filter factory, so we deal with it
by keeping around a compatibility implementation which just does
nothing like before.

TX


On Tue, 25 Jun 2019 at 06:21, <baris.kazar@oracle.com> wrote:
>
> According to this jira ticket, where else is StandardFilter included in
> Lucene 8.1.1?
>
> and why is it a no-op now in Lucene 8.1.1?
>
> I wish the tickets were a bit more explicit and suggest what to use
> instead for deprecated versions like in version 7.5.0 or why it became
> no-op in version 8.1.1?
>
> this will make easy when ugrading to later versions.
>
> Thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: StanardFilter Question : https://issues.apache.org/jira/browse/LUCENE-8356 [ In reply to ]
Yeah, that code looks right to me.

The factory we use for keeping backwards compatibility is entirely
ours. I think CustomAnalyzer is a similar-looking API to what we have
but we made ours much earlier and it supports analysis stuff all the
way back to Lucene 3 which we migrated all the way to where we are
now.

TX

On Wed, 26 Jun 2019 at 06:47, <baris.kazar@oracle.com> wrote:
>
> Corrected a typo below in the new code.
>
> Best regards
>
>
> On 6/25/19 5:01 PM, baris.kazar@oracle.com wrote:
> > Hi,-
> >
> > do You mean there is a backward compatibility factory in Lucene for
> > these kinds of cases?
> >
> > i think it can be fixed like this, In other words is the following
> > first line redundant then?
> >
> > TokenStream filter = new StandardFilter(tokenizer); -> redundant
> > (tokenizer is actually a StandardTokenizer object).
> > filter = new ElisionFilter(filter, getDefaultArticles());-> tokenizer
> > can be directly used here
> >
> > filter = new LowerCaseFilter(filter);
> >
> > ->
> >
> > TokenStream filter = new ElisionFilter(*tokenizer*,
> > getDefaultArticles());*//not filter here*
> >
> > filter = new LowerCaseFilter(filter);
> >
> >
> > I also saw that some public fields have now different return type like
> > org.apache.lucene.search.TopDocs.totalHits field which is long type now.
> >
> > this affects my rest of the code very much but luckliy there is
> > Math.toIntExact which throws ArithmeticException when number is really
> > long number outside integer limit.
> >
> > In my case i will not exceed integer limit anyways.
> >
> >
> > Best regards
> >
> >
> > On 6/24/19 5:19 PM, Trejkaz wrote:
> >> I did the research on this one because it confused me as well, but it
> >> seems it was a no-op. So the replacement is just to remove it from the
> >> filter chain.
> >>
> >> We have a backwards compatibility filter factory, so we deal with it
> >> by keeping around a compatibility implementation which just does
> >> nothing like before.
> >>
> >> TX
> >>
> >>
> >> On Tue, 25 Jun 2019 at 06:21, <baris.kazar@oracle.com> wrote:
> >>> According to this jira ticket, where else is StandardFilter included in
> >>> Lucene 8.1.1?
> >>>
> >>> and why is it a no-op now in Lucene 8.1.1?
> >>>
> >>> I wish the tickets were a bit more explicit and suggest what to use
> >>> instead for deprecated versions like in version 7.5.0 or why it became
> >>> no-op in version 8.1.1?
> >>>
> >>> this will make easy when ugrading to later versions.
> >>>
> >>> Thanks
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: StanardFilter Question : https://issues.apache.org/jira/browse/LUCENE-8356 [ In reply to ]
Hi,-

 do You mean there is a backward compatibility factory in Lucene for
these kinds of cases?

i think it can be fixed like this,  In other words is the following
first line redundant then?

TokenStream filter = new StandardFilter(tokenizer); -> redundant
(tokenizer is actually a StandardTokenizer object).
filter = new ElisionFilter(filter, getDefaultArticles());-> tokenizer
can be directly used here

filter = new LowerCaseFilter(filter);

->

TokenStream filter = new ElisionFilter(filter, getDefaultArticles());

filter = new LowerCaseFilter(filter);


I also saw that some public fields have now different return type like
org.apache.lucene.search.TopDocs.totalHits field which is long type now.

this affects my rest of the code very much but luckliy there is
Math.toIntExact which throws ArithmeticException when number is really
long number outside integer limit.

In my case i will not exceed integer limit anyways.


Best regards


On 6/24/19 5:19 PM, Trejkaz wrote:
> I did the research on this one because it confused me as well, but it
> seems it was a no-op. So the replacement is just to remove it from the
> filter chain.
>
> We have a backwards compatibility filter factory, so we deal with it
> by keeping around a compatibility implementation which just does
> nothing like before.
>
> TX
>
>
> On Tue, 25 Jun 2019 at 06:21, <baris.kazar@oracle.com> wrote:
>> According to this jira ticket, where else is StandardFilter included in
>> Lucene 8.1.1?
>>
>> and why is it a no-op now in Lucene 8.1.1?
>>
>> I wish the tickets were a bit more explicit and suggest what to use
>> instead for deprecated versions like in version 7.5.0 or why it became
>> no-op in version 8.1.1?
>>
>> this will make easy when ugrading to later versions.
>>
>> Thanks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: StanardFilter Question : https://issues.apache.org/jira/browse/LUCENE-8356 [ In reply to ]
Corrected a typo below in the new code.

Best regards


On 6/25/19 5:01 PM, baris.kazar@oracle.com wrote:
> Hi,-
>
>  do You mean there is a backward compatibility factory in Lucene for
> these kinds of cases?
>
> i think it can be fixed like this,  In other words is the following
> first line redundant then?
>
> TokenStream filter = new StandardFilter(tokenizer); -> redundant
> (tokenizer is actually a StandardTokenizer object).
> filter = new ElisionFilter(filter, getDefaultArticles());-> tokenizer
> can be directly used here
>
> filter = new LowerCaseFilter(filter);
>
> ->
>
> TokenStream filter = new ElisionFilter(*tokenizer*,
> getDefaultArticles());*//not filter here*
>
> filter = new LowerCaseFilter(filter);
>
>
> I also saw that some public fields have now different return type like
> org.apache.lucene.search.TopDocs.totalHits field which is long type now.
>
> this affects my rest of the code very much but luckliy there is
> Math.toIntExact which throws ArithmeticException when number is really
> long number outside integer limit.
>
> In my case i will not exceed integer limit anyways.
>
>
> Best regards
>
>
> On 6/24/19 5:19 PM, Trejkaz wrote:
>> I did the research on this one because it confused me as well, but it
>> seems it was a no-op. So the replacement is just to remove it from the
>> filter chain.
>>
>> We have a backwards compatibility filter factory, so we deal with it
>> by keeping around a compatibility implementation which just does
>> nothing like before.
>>
>> TX
>>
>>
>> On Tue, 25 Jun 2019 at 06:21, <baris.kazar@oracle.com> wrote:
>>> According to this jira ticket, where else is StandardFilter included in
>>> Lucene 8.1.1?
>>>
>>> and why is it a no-op now in Lucene 8.1.1?
>>>
>>> I wish the tickets were a bit more explicit and suggest what to use
>>> instead for deprecated versions like in version 7.5.0 or why it became
>>> no-op in version 8.1.1?
>>>
>>> this will make easy when ugrading to later versions.
>>>
>>> Thanks
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>