[
https://issues.apache.org/jira/browse/LUCENE-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888899#comment-13888899
]
Michael McCandless commented on LUCENE-5404:
--------------------------------------------
I think it's a little strange to load the count in super's .load(InputStream)
method, and then fwd to sub's .load(DataInput)?
(Separately I think it's good to switch .store/.load from
OutputStream/InputStream to DataOutput/DataInput).
Maybe ... we can just do the change from "void build" to "int build", and not
worry about adding a .getCount() from a load'd suggester. This way the app
knows how many suggestions were built when creating the suggester and if really
cares to persist this info it can do so itself? Or, we can keep the .getCount,
but have each suggester handle writing/reading it itself? I just think it's
odd to have super write/read this ...
It's also not great how these suggesters don't use CodecUtil.write/readHeader
to make sure the file they are loading is in fact something that this suggester
had previously .stored ... but we can fix that separately.
> Add support to get number of entries a Suggester Lookup was built with and
> minor refactorings
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-5404
> URL: https://issues.apache.org/jira/browse/LUCENE-5404
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Areek Zillur
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5404.patch, LUCENE-5404.patch, LUCENE-5404.patch
>
>
> It would be nice to be able to tell the number of entries a suggester lookup
> was built with. This would let components using lookups to keep some stats
> regarding how many entries were used to build a lookup.
> Additionally, Dictionary could use InputIterator rather than the
> BytesRefIteratator, as most of the implmentations now use it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
