[
https://issues.apache.org/jira/browse/LUCENE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971830#comment-16971830
]
Jason Gerlowski commented on LUCENE-9026:
-----------------------------------------
Thanks for the pointer Mikhail. I looked at using
{{method=docValuesTermsFilter}} for my use case, and it did do better than the
default "method", but it's not the most efficient implementation possible. (I
have an alternate implementation that's done much better for us up for review
on SOLR-13890, if you're curious.)
That said, making DVTQ more subclass/composition friendly is a generally good
thing, regardless of whether we go forward with SOLR-13890. So I plan on
committing this small change later this evening.
> Make it easier to extend DocValuesTermsQuery
> --------------------------------------------
>
> Key: LUCENE-9026
> URL: https://issues.apache.org/jira/browse/LUCENE-9026
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Affects Versions: master (9.0)
> Reporter: Jason Gerlowski
> Priority: Minor
> Attachments: LUCENESOLR-9026.patch
>
>
> The visibility of some of the fields in DocValuesTermsQuery make it difficult
> to efficiently subclass. Especially the "termData" instance variable, which
> is really core to the functioning of the class but is totally inaccessible
> from any sub-classes, forcing subclasses to store a duplicate
> PrefixCodedTerms object, and then juggle the state of both.
> Are there any objections to making "termData" (and potentiall some other
> instance variables) protected instead of private for this class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
