[
https://issues.apache.org/jira/browse/LUCENE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121368#comment-13121368
]
Mark Miller commented on LUCENE-3488:
-------------------------------------
bq. see my comment: "i am not saying we should but if we take.."
I'm not arguing about that - I'm just commenting on your comment.
bq. but hey as long as you can wrap your head around public
RefCounted<SolrIndexSearcher> getSearcher(...) fine, I can't!
Well, if you take out all of the things that it's doing above and beyond these
manager classes, sure it would be a much leaner class ... but thats more than a
few features removed... removed features generally means less code.
I'm not saying it's not a method that couldn't be broken down or refactored to
be made more clear - but as someone that has written classes like these manager
classes, and has worked closely on this area of Solr, I'm just not finding
these comments jive with my experience. People love to jump on Solr code, but
generally it's not very strong arguments. The UpdateHandler was redesigned IMO
- I tackled that with an open page. If someone thinks it should be redesigned
further, the proof is in the pudding. I'm happy where I took it at the moment.
Wasn't a big redesign because in the end, that was not necessary - it was not a
bad design to start - some of it was simply dated compared to Lucene
advancements.
> Factor out SearcherManager from NRTManager
> ------------------------------------------
>
> Key: LUCENE-3488
> URL: https://issues.apache.org/jira/browse/LUCENE-3488
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 3.5, 4.0
> Reporter: Simon Willnauer
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3488.patch
>
>
> Currently we have NRTManager and SearcherManager while NRTManager contains a
> big piece of the code that is already in SearcherManager. Users are kind of
> forced to use NRTManager if they want to have SearcherManager goodness with
> NRT. The integration into NRTManager also forces you to maintain two
> instances even if you know you always want deletes. To me NRTManager tries to
> do more than necessary and mixes lots of responsibilities ie. handling
> searchers and handling indexing generations. NRTManager should use a
> SearcherManager by aggregation rather than duplicate a lot of logic.
> SearcherManager should have a NRT and Directory based implementation users
> can simply choose from.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
