lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <>
Subject [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Date Wed, 24 Nov 2010 23:29:15 GMT


Earwin Burrfoot commented on LUCENE-2691:

You're still okay with an API that allows you to reopen IRs on different directories?
Let us introduce then, instead of bothering with APIs, a single class with method 'void doStuff(Object...
args)' that, inside, has an elaborate logic validating and interpreting said arguments and
then doing a fat switch to execute corresponding computations.

I think reopen should have no parameters, and IR.reopen(IC) moved elsewhere.

I'd personally like to see a special subclass of DIR that is returned from IW.getReader(),
that knows about specifics of being opened over an active writer.
Something along the lines of -
This also removes said specifics in form of of stupid if-checks and unnecessary fields from
actual DIR. Modes should be done with subclasses, not switches, dammit! :)

If we allow reopen to switch readers between modes, we're introducing yet more checking and
switching around.
Also we'll get irreversible circular dependency between readers and writers, which is also
a sign of things going wrong.

> Consolidate Near Real Time and Reopen API semantics
> ---------------------------------------------------
>                 Key: LUCENE-2691
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>            Priority: Minor
>             Fix For: 4.0
>         Attachments: LUCENE-2691.patch, LUCENE-2691.patch
> We should consolidate the IndexWriter.getReader and the IndexReader.reopen semantics,
since most people are already using the IR.reopen() method, we should simply add::
> {code}
> IR.reopen(IndexWriter)
> {code}
> Initially, it could just call the IW.getReader(), but it probably should switch to just
using package private methods for sharing the internals

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message