[jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics

2011-01-20 Thread Michael McCandless (JIRA)

[ 
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

2010-11-25 Thread Michael McCandless (JIRA)

[ 
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

2010-11-25 Thread Earwin Burrfoot (JIRA)

[ 
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

2010-11-25 Thread eks dev
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

2010-11-25 Thread Earwin Burrfoot
 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

2010-11-24 Thread Grant Ingersoll (JIRA)

[ 
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

2010-11-24 Thread Earwin Burrfoot (JIRA)

[ 
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

2010-11-19 Thread Michael McCandless (JIRA)

[ 
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

2010-10-13 Thread Yonik Seeley (JIRA)

[ 
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

2010-10-10 Thread Grant Ingersoll (JIRA)

[ 
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

2010-10-10 Thread Simon Willnauer (JIRA)

[ 
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

2010-10-09 Thread Michael McCandless (JIRA)

[ 
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

2010-10-09 Thread Grant Ingersoll (JIRA)

[ 
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

2010-10-09 Thread Michael McCandless (JIRA)

[ 
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

2010-10-09 Thread Michael McCandless (JIRA)

[ 
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

2010-10-09 Thread Michael McCandless (JIRA)

[ 
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