lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-5970) Remove IndexReaderContext/CompositeReaderContext/AtomicReaderContext
Date Wed, 15 Oct 2014 23:16:33 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14173131#comment-14173131
] 

Robert Muir commented on LUCENE-5970:
-------------------------------------

My problem is how special cases (like 3 DRs -> one multireader) completely screw up the
api for the simple cases. In your example there, MultiReader could easily handle it itself:
so the expert shit stays exactly where it belongs, instead of being in the way of all queries.

This api currently introduces useless indirection etc, in my opinion is totally unnecessary.


The problems with how hard it is to maintain some reader subclass, are more about how the
IR api looked before (it was more complicated to subclass).

If you are so hellbent on keeping it, then fine, but keeping these contexts around doesnt
mean we have to let them infect every api. I am happy to instead to try to remove them and
keep them away at a fine-grained level from as many methods as possible, instead passing things
like AtomicReader + docBase unless there is a clearly justified reason to do otherwise for
each, individual, API.

> Remove IndexReaderContext/CompositeReaderContext/AtomicReaderContext
> --------------------------------------------------------------------
>
>                 Key: LUCENE-5970
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5970
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>
> This hierarchy is mega-confusing, has a overcomplicated hierarchy, and is full of bugs.
> For example, in a two-segment index with one document in each:
> {code}
> context.docbase: 1
> context.reader().getContext().docBase: 0
> {Code}
> There is just no need for all this. We can replace it all with 'docbase'. For the esoteric
stuff solr wants to do, like top-level crap, it can do this with its own filterreader instead,
rather than pushing the complexity into lucene.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message