lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3807) Cleanup suggester API
Date Wed, 22 Feb 2012 10:48:48 GMT


Simon Willnauer commented on LUCENE-3807:

bq. This shows up in a number of places. I have mixed feelings about certain types having
a comparator and others not having it, but it's minor.
well this an indicator if we know something about the order or not. if you get null there
is not order specified...

bq. BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It would be nicer
to have a sort on disk if something doesn't support sorted iteration order.
this is the ultimate goal... see my comment above ({noformat} next steps would be cleaning
up the in-memory sorting stuff and use the sorter which goes to disk to do the actual sorting
internally if needed {noformat})

bq. I also wonder float -> long = 4 -> 8 bytes... would this count as an incompatible
API change (because what used to work for a given amount of RAM won't work anymore – BufferingTermFreqIteratorWrapper

see above

bq. if I remember correctly Math.min/max are intrinsics, so you can afford to be explicit

I will upload a new patch - we use this in BytesRefComp too, I think its safe to fix

bq. This doesn't seem necessary (lookup accepts a CharSequence?).
right - leftover from an old iteration

bq. Why not a specific covariant here?
that would be Float get(String) or Float get(CharSequence) or... ;)

> Cleanup suggester API
> ---------------------
>                 Key: LUCENE-3807
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: modules/other
>    Affects Versions: 3.6, 4.0
>            Reporter: Simon Willnauer
>             Fix For: 4.0
>         Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch
> Currently the suggester api and especially TermFreqIterator don't play that nice with
BytesRef and other paradigms we use in lucene, further the java iterator pattern isn't that
useful when it gets to work with TermsEnum, BytesRef etc. We should try to clean up this api
step by step moving over to BytesRef including the Lookup class and its interface...

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message