[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