[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12984302#action_12984302
]
Michael McCandless commented on LUCENE-2691:
I'll backport...
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Michael McCandless
Priority: Minor
Fix For: 3.1, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935767#action_12935767
]
Michael McCandless commented on LUCENE-2691:
bq. You're still okay with an API that allows you to reopen IRs on different
directories?
Well, that's no good - we can catch this and throw an exc?
bq. I think reopen should have no parameters, and IR.reopen(IC) moved elsewhere.
But where would you move IR.reopen(IC)?
bq. 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.
That sounds great!
{quote}
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.
{quote}
Really, there are two separate things open/reopen needs:
# The SegmentInfos -- either by finding the latest greatest in the
Directory, latest greatest via IW, or explicitly via an
IndexCommit.
# A prior pool of readers so that anything needing a reader (IW
doing a merge, IW applying deletes, app opening new readers, etc.)
can re-use any already open sub readers.
Maybe we can split these out.
EG we've wanted for a while now to factor out the reader pool hidden
inside IW. If we did this, and then allowed optionally passing a pool
to IR.open, I think we could do away with IR.reopen entirely? We'd
have variants of IR.open taking IW, Dir, IndexCommit, to say where the
SegmentInfos come from, and then optionally also taking the explicit
reader pool.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935794#action_12935794
]
Earwin Burrfoot commented on LUCENE-2691:
-
{quote}
bq. You're still okay with an API that allows you to reopen IRs on different
directories?
Well, that's no good - we can catch this and throw an exc?
{quote}
I don't understand why should we bother with checking and throwing exceptions,
when we can prevent such things from compiling at all.
By using an API, that doesn't support reopening on anything different from
original source.
bq. Really, there are two separate things open/reopen needs:
That's not true. Take a look at my WriterBackedReader above (or DirectoryReader
in trunk). It requires writer at least to call deleteUnusedFiles(),
nrtIsCurrent().
So you can't easily reopen between Directory-backed and Writer-backed readers
without much switching and checking.
bq. r_ram.reload(); //Here we want to reload from the FSDirecotory?
Use MMapDirectory? It's only a bit slower for searches, while not raping your
GC on big indexes.
Also check this out - https://gist.github.com/715617 , it is a RAMDirectory
offspring that wraps any other given directory and basically does what you want
(if I guessed right).
It doesn't use blocking for files, so file size limit is 2Gb, but this can be
easily fixed. On the up side - it reads file into memory only after the size is
known (unlike RAMDir), which allows you to use huge precisely-sized blocks,
lessening GC pressure.
I used it for a long time, but then my indexes grew, heaps followed, VM
exploded and I switched to MMapDirectory (with minor patches).
bq. What is missing is a signal from IR.reload() to RAMdirectory to slurp
fresh information from FSDirecory?
There is zero need for any such signal. If a reader requests non-existing file
from RAMDirectory, it should check backing dir before throwing exception. If
backing dir does have the file - it is loaded and opened.
Why do you people love complicating things that much? :)
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Earwin, I used MMAP a lot, is quite nice, it has its place under the sun,
but it is not a silver bullet, it has its quirks... the same goes for
RAMDirectory.
bq. There is zero need for any such signal. ...non-existing file ...
Why would IndexReader ever try to read non-existing file? IR is going to see
its RAMDirectory point-in-time snapshot of an Index until you somehow try to
reload updated Index image on disk.
On Thu, Nov 25, 2010 at 6:00 PM, Earwin Burrfoot (JIRA) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935794#action_12935794]
Earwin Burrfoot commented on LUCENE-2691:
-
{quote}
bq. You're still okay with an API that allows you to reopen IRs on
different directories?
Well, that's no good - we can catch this and throw an exc?
{quote}
I don't understand why should we bother with checking and throwing
exceptions, when we can prevent such things from compiling at all.
By using an API, that doesn't support reopening on anything different from
original source.
bq. Really, there are two separate things open/reopen needs:
That's not true. Take a look at my WriterBackedReader above (or
DirectoryReader in trunk). It requires writer at least to call
deleteUnusedFiles(), nrtIsCurrent().
So you can't easily reopen between Directory-backed and Writer-backed
readers without much switching and checking.
bq. r_ram.reload(); //Here we want to reload from the FSDirecotory?
Use MMapDirectory? It's only a bit slower for searches, while not raping
your GC on big indexes.
Also check this out - https://gist.github.com/715617 , it is a
RAMDirectory offspring that wraps any other given directory and basically
does what you want (if I guessed right).
It doesn't use blocking for files, so file size limit is 2Gb, but this can
be easily fixed. On the up side - it reads file into memory only after the
size is known (unlike RAMDir), which allows you to use huge precisely-sized
blocks, lessening GC pressure.
I used it for a long time, but then my indexes grew, heaps followed, VM
exploded and I switched to MMapDirectory (with minor patches).
bq. What is missing is a signal from IR.reload() to RAMdirectory to slurp
fresh information from FSDirecory?
There is zero need for any such signal. If a reader requests non-existing
file from RAMDirectory, it should check backing dir before throwing
exception. If backing dir does have the file - it is loaded and opened.
Why do you people love complicating things that much? :)
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Earwin, I used MMAP a lot, is quite nice, it has its place under the sun,
but it is not a silver bullet, it has its quirks... the same goes for
RAMDirectory.
Ok, I pointed you to a directory that can be wrapped over FSDirectory
and loads files into memory buffer, when queried.
bq. There is zero need for any such signal. ...non-existing file ...
Why would IndexReader ever try to read non-existing file? IR is going to see
its RAMDirectory point-in-time snapshot of an Index until you somehow try to
reload updated Index image on disk.
What is your aim?
Have a RAMDir pre-loaded from FSDir, open your reader over this
RAMDir, and when you reopen the reader you want the contents of RAMDir
to be updated. Riiight?
Very well, have your RAMDir delegating listFiles call to backing
FSDir, so reader knows which files do exist and when actually tries to
open a file that exists on disk, but haven't been opened before - your
directory loads it to memory.
If you want, you can also refcount files when they are opened/closed,
and if file is no longer used, you drop it from memory (leaving disk
copy intact).
There's no reason at all for the Reader to know that his Directory
might be a proxy and notify it of anything else besides opening and
closing files. Proxying can be completely transparent.
On Thu, Nov 25, 2010 at 6:00 PM, Earwin Burrfoot (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935794#action_12935794
]
Earwin Burrfoot commented on LUCENE-2691:
-
{quote}
bq. You're still okay with an API that allows you to reopen IRs on
different directories?
Well, that's no good - we can catch this and throw an exc?
{quote}
I don't understand why should we bother with checking and throwing
exceptions, when we can prevent such things from compiling at all.
By using an API, that doesn't support reopening on anything different from
original source.
bq. Really, there are two separate things open/reopen needs:
That's not true. Take a look at my WriterBackedReader above (or
DirectoryReader in trunk). It requires writer at least to call
deleteUnusedFiles(), nrtIsCurrent().
So you can't easily reopen between Directory-backed and Writer-backed
readers without much switching and checking.
bq. r_ram.reload(); //Here we want to reload from the FSDirecotory?
Use MMapDirectory? It's only a bit slower for searches, while not raping
your GC on big indexes.
Also check this out - https://gist.github.com/715617 , it is a
RAMDirectory offspring that wraps any other given directory and basically
does what you want (if I guessed right).
It doesn't use blocking for files, so file size limit is 2Gb, but this can
be easily fixed. On the up side - it reads file into memory only after the
size is known (unlike RAMDir), which allows you to use huge precisely-sized
blocks, lessening GC pressure.
I used it for a long time, but then my indexes grew, heaps followed, VM
exploded and I switched to MMapDirectory (with minor patches).
bq. What is missing is a signal from IR.reload() to RAMdirectory to
slurp fresh information from FSDirecory?
There is zero need for any such signal. If a reader requests non-existing
file from RAMDirectory, it should check backing dir before throwing
exception. If backing dir does have the file - it is loaded and opened.
Why do you people love complicating things that much? :)
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935347#action_12935347
]
Grant Ingersoll commented on LUCENE-2691:
-
I don't have a problem with it, but I don't see how it is any more confusing
that reopening on a IndexCommit. In my mind, the thing you are reopening is a
set of segments. Unfortunately, we don't have a access in a clean way to get
the IndexWriter's segment, so we pass in the IW. The whole point of IR.reopen
is you are getting a new reader on an index. Presumably, the IW is on the same
Directory, just like presumably the CommitPoint is on the same Directory.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935569#action_12935569
]
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 - https://gist.github.com/d5a197a001c24fccb1b5
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: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933803#action_12933803
]
Michael McCandless commented on LUCENE-2691:
I also think we shouldn't add a reopen(IW) here, since you can just IR.open(IW)
and then call its .reopen(). It's confusing to IR.open(Dir) and then later
IR.reopen(IW) on it.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920581#action_12920581
]
Yonik Seeley commented on LUCENE-2691:
--
I think I agree Earwin... it's not clear what functionality was added with this
patch, just a vague notion of consolidating semantics. Adding more ways to do
the same thing in this case just seems to complicate the API.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919591#action_12919591
]
Grant Ingersoll commented on LUCENE-2691:
-
Simon, I think you are right, as the necessary sync blocks are in the
underlying getReader() call on IW. I just copied the signatures. I will put
up a new patch.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
Attachments: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919620#action_12919620
]
Simon Willnauer commented on LUCENE-2691:
-
bq. Ready to go.
+1 looks good to me
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919498#action_12919498
]
Michael McCandless commented on LUCENE-2691:
+1!
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919499#action_12919499
]
Grant Ingersoll commented on LUCENE-2691:
-
What's with all of the test dependencies on IndexWriter.getReader() that
seemingly don't have anything to do with NRT? For instance,
TestQueryParser.testPositionIncrements() or TestCachingSpanFilter?
If we insist on those, then it seems we'll have to add an
IndexReader.open(IndexWriter) method (plus, I suppose a couple of variations).
This concerns me b/c there are already more than enough variations on that
method, but what's one more?
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919503#action_12919503
]
Michael McCandless commented on LUCENE-2691:
bq. What's with all of the test dependencies on IndexWriter.getReader() that
seemingly don't have anything to do with NRT? For instance,
TestQueryParser.testPositionIncrements() or TestCachingSpanFilter?
This is just because those tests need a reader having just built the index...
ie, as long as there's no other reason to .commit, getting the reader from the
writer is perfectly fine.
Plus this only increases test coverage of NRT.
RandomIndexWriter's .getReader method now randomly picks to either get the
reader from the writer, or, to .commit and then open a new reader.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919504#action_12919504
]
Michael McCandless commented on LUCENE-2691:
bq. we'll have to add an IndexReader.open(IndexWriter) method (plus, I suppose
a couple of variations).
+1
I think IR.open(IW) makes sense.
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12919533#action_12919533
]
Michael McCandless commented on LUCENE-2691:
patch looks great Grant!
I think we don't need the IR.open that takes a termInfosIndexDivisor... and we
also don't need the IW.getReader that takes one too. We had added these before
adding IWC.set/getReaderTermsIndexDivisor...
Consolidate Near Real Time and Reopen API semantics
---
Key: LUCENE-2691
URL: https://issues.apache.org/jira/browse/LUCENE-2691
Project: Lucene - Java
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 3.1, 4.0
Attachments: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
