> > Because I think we should avoid reference counting in our apis! >
It doesn't make sense to me. You make it sound like a bad thing. If an object requires reference counting, why do you want to discourage that? I understand why its on IR, but i dont think it should spread. > Again, this sounds negative. If DirTaxoReader needs it, because it is not cheap to init for every search, and you want to share it between search requests, what will be the alternative? Reference counting is appropriate in some cases. You could claim the same about TwoPhaseCommit -- should we discourage objects that should (and can) from supporting TPC? Because indexsearcher is about things like searching and scoring (not > opening and closing readers). > I'm not sure why you make this distinction. True, it is lighter-weight than IndexReader, but we still have SearcherManager and not ReaderManager, so obviously someone thought that it's not as cheap to init an IndexSearcher for every search request (otherwise, you wouldn't need LUCENE-3636 right?). Shai On Sun, Dec 11, 2011 at 3:25 PM, Robert Muir <[email protected]> wrote: > On Sun, Dec 11, 2011 at 8:16 AM, Shai Erera <[email protected]> wrote: > >> I dunno, I'm not really sure we should encourage adding more reference > >> counting to Lucene (I think we should discourage instead!) > > > > > > But we already have (DirectoryTaxonomyReader). Why should we discourage > > that? > > Because I think we should avoid reference counting in our apis! I > understand why its on IR, but i dont think it shoudl spread. > > > > > > >> Lets please not do this! > > > > > > Why? Today whoever manages IndexSearcher instances needs to call > > s.getIndexReader().incRef()/decRef(). Why not call on IndexSearcher > itself? > > Because indexsearcher is about things like searching and scoring (not > opening and closing readers). > > -- > lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
