How about using a FuzzyQuery and using a Rewrite subclass to collect terms?
This works with all MultiTermQuery subclasses.
Basically you set a custom rewrite (I think you want ScoringRewrite) that
collects the terms and rewrite to nothing (e.g. MatchNoDocsQuery). You just
rewrite the
I am trying to upgrade my project to Lucene 8.5 from 8.4 and have hit a
snag. I had been using
the FuzzyTermEnum constructor:
FuzzyTermsEnum(Terms terms, AttributeSource atts, Term term, int maxEdits,
int prefixLength, boolean transpositions) throws IOException
This constructor is no longer
Michael:
If you’d like to have a go at it, please feel free. The easiest way I’ve found
is, in master, execute the “assemble” task from the Gradle window in IntelliJ
(no clue about Eclipse, but I suspect there’s something similar). Since Lucene
has < 100 warnings, you don’t even have to fiddle
Uwe:
In that case we can ignore the question, this was just a reflex on my part.
> On Jun 7, 2020, at 11:38 AM, Uwe Schindler wrote:
>
> Hi,
>
> The main reason to use StringBuffer ist legacy Apis. One example is all
> Formatters low level apis (DecimalFormat, Formatter,...) Use StringBuffer
Hi,
The main reason to use StringBuffer ist legacy Apis. One example is all
Formatters low level apis (DecimalFormat, Formatter,...) Use StringBuffer to
implement itsself.
Nowadays there is no performance impact anymore. If you use StringBuffer from
one thread, JVM removes the
On 06/06/2020 22:48, Erick Erickson wrote:
> When is there a good reason to use StringBuffer rather than StringBuilder?
> While going through some of the warnings I happened to run across a few of
> these. I haven’t changed them, and at least one (AuditEvent) has a comment
> about back-compat
I'm all for it. Warnings can be useful if we pay attention to them, which
means cleaning up the ones we don't want to pay attention to, addressing
others as they arise, etc. I would be +1 to a warning free build, and I
will help if you break off a piece, thanks for kicking this off
On Sun, Jun 7,
There are about 100 compile-time warnings in Lucene, not including
deprecations. I’m trying to get all the warnings out or suppressed so we can
stop backsliding by turning up compilation errors to include selected warnings.
But I don’t want to muck with Lucene without some consensus on whether
Thanks Ilan:
Suppressing forbidden api check for specific methods is easy, BTW.
@SuppressForbidden(reason=“explanatory note”)
> On Jun 6, 2020, at 7:05 PM, Ilan Ginzburg wrote:
>
> From
> https://stackoverflow.com/questions/355089/difference-between-stringbuilder-and-stringbuffer
>
> “
