[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13216794#comment-13216794
]
Bill Bell commented on LUCENE-3360:
---
+1 for FieldCache being an impl of DocValues.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214451#comment-13214451
]
Ryan McKinley commented on LUCENE-3360:
---
wow, lots has changed since the last patch! I *think* all the reader/cache
refactoring has settled down, so this would be good to get sorted soon.
I ran it through the LUCENE-3753.patch.hack.pl but there are enough changes,
that it is significant work to resurrect from the patch; it may be more
effective to refactor the code.
Martijn, you interested in picking this up again? If no, i may give it a try.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214473#comment-13214473
]
Martijn van Groningen commented on LUCENE-3360:
---
Hi Ryan! Yeah, a lot has changed since the last patch. This issue is on my task
list, however so are other issues. I was planning to pick this in the coming
weeks. If you have time now it would be great to continue the work on this
issue now. To sooner we get rid of the FieldCache#DEFAULT the better!
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214609#comment-13214609
]
Uwe Schindler commented on LUCENE-3360:
---
Hi,
in my opinion, the whole FieldCache is obsolete somehow, since we have
DocValues in trunk. If we still want some on-the-fly uninverting, we can
simply expose that as another DocValues impl. Why does FieldCache needs to be
separate? DocValues is the API and FieldCache can simply be another one not
materialized on disk.
One cool thing about a separate FieldCache DocValues impl would be that you
could merge... Means: A 3.x index without DocValues could on the next merge be
a 4.x segment with DocValues that were merged on the fly from the 3.x index by
uninverting :-) For trunk indexes we require docvalues to facet, group,
sort,... The 3.x codec would simply simulate that by doing uninversion. Once
those old 3.x segments are merged to new 4.x segments, docvalues materialize
from the on-they-fly 3.x fieldcache docvalues.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13149326#comment-13149326
]
Michael McCandless commented on LUCENE-3360:
I think this can proceed, now that LUCENE-3443 is done!
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.5, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118043#comment-13118043
]
Martijn van Groningen commented on LUCENE-3360:
---
I don't see a patch for LUCENE-3443 yet. Maybe we can forward port [this issue
including FieldCache.getDocsWithField() to
trunk|http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-09-25#l692]?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.5, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118048#comment-13118048
]
Uwe Schindler commented on LUCENE-3360:
---
bq. Maybe we can forward port this issue including
FieldCache.getDocsWithField() to trunk?
That was the plan. But first we need to revert the current impl in trunk :(
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.5, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118192#comment-13118192
]
Martijn van Groningen commented on LUCENE-3360:
---
bq. That was the plan. But first we need to revert the current impl in trunk
I think I missed that. Can you point to the code and svn revision in trunk?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.5, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086258#comment-13086258
]
Michael McCandless commented on LUCENE-3360:
I actually prefer the name AtomicFieldCache, since this matches other
places (eg. AtomicReaderContext), and because it's not necessarily a
segment (SlowMultiReaderWrapper returns an instance).
The name SegmentFieldCacheImpl seems OK, but can't this class be
package private?
I love the name InsaneFieldCache!
For the new IR.getFieldCache() instead of a generic UOE can we throw
something like MR.fields() throws? Ie the exc message should explain
that you should use the SlowMRWrapper instead.
I'm nervous about how the [deprecated] FC makes a new SlowMRWrapper()
for each getXXX call -- I think this class uses this as the
getFieldCacheKey? Won't this mean each lookup will build a new cache
entry? (Hmm... but then why don't tests fail... I think we have at
least one test verifying same instance is returned for 2 calls in a
row).
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086260#comment-13086260
]
Robert Muir commented on LUCENE-3360:
-
{quote}
For the new IR.getFieldCache() instead of a generic UOE can we throw
something like MR.fields() throws? Ie the exc message should explain
that you should use the SlowMRWrapper instead.
{quote}
Yeah, can we force the user to make their own SlowMultiReaderWrapper? I don't
think we should ever create such things, even for deprecated stuff in 4.0
In 4.0 we just change the API and make you create it yourself.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086276#comment-13086276
]
Michael McCandless commented on LUCENE-3360:
bq. In 4.0 we just change the API and make you create it yourself.
+1
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086275#comment-13086275
]
Michael McCandless commented on LUCENE-3360:
bq. In 4.0 we just change the API and make you create it yourself.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086278#comment-13086278
]
Martijn van Groningen commented on LUCENE-3360:
---
{quote}
I actually prefer the name AtomicFieldCache, since this matches other
places (eg. AtomicReaderContext), and because it's not necessarily a
segment (SlowMultiReaderWrapper returns an instance).
{quote}
For naming consistency I agree with you there. I will make the
SegmentFieldCacheImpl package private. I kept it in the patch it public, b/c
FieldCacheImpl was public too.
{quote}
I'm nervous about how the [deprecated] FC makes a new SlowMRWrapper()
for each getXXX call – I think this class uses this as the
getFieldCacheKey? Won't this mean each lookup will build a new cache
entry? (Hmm... but then why don't tests fail... I think we have at
least one test verifying same instance is returned for 2 calls in a
row).
{quote}
The current FielCache api requires a reader to be specified. That specified
reader is used as key.
bq. I love the name InsaneFieldCache!
I love the name too :)
bq. In 4.0 we just change the API and make you create it yourself.
So remove [deprecated] FieldCache completely? When back porting to 3x we
obviously need to keep FieldCache classes...
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086291#comment-13086291
]
Michael McCandless commented on LUCENE-3360:
bq. The current FielCache api requires a reader to be specified. That specified
reader is used as key.
Ahh I see -- the SlowMRWrapper's FC impl uses the in (wrapped IndexReader,
from FilterIndexReader) as the key. So we should only see one cache entry
created. Phew!
bq. When back porting to 3x we obviously need to keep FieldCache classes...
True... so maybe do this patch in 2 steps? First, for 3.x. Then, merge to
trunk, remove deprecated FC and fix all usages?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086295#comment-13086295
]
Uwe Schindler commented on LUCENE-3360:
---
Thanks, for taking care! I am a little bit over-crowded with summer-holidays :-)
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086494#comment-13086494
]
Martijn van Groningen commented on LUCENE-3360:
---
bq. True... so maybe do this patch in 2 steps? First, for 3.x. Then, merge to
trunk, remove deprecated FC and fix all usages?
Proposal: Get everything to work with the current deprecated FieldCache. Port
to working code to 3x. Remove deprecated FieldCache from trunk and move its
inner classes (like DocTermsIndex) to search.cache.
FieldCache has also some static *_PARSER fields that are used in the
*ValuesCreator classes. I think these fields should move to *ValuesCreator
classes as private fields. Besides the tests these fields are only used in
*ValuesCreator classes.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086497#comment-13086497
]
Uwe Schindler commented on LUCENE-3360:
---
bq. FieldCache has also some static *_PARSER fields that are used in the
*ValuesCreator classes. I think these fields should move to *ValuesCreator
classes as private fields. Besides the tests these fields are only used in
*ValuesCreator classes.
They should only be public available... If ValueCreate classes are package
private then its not good. The parsers are oftenh used when the field type is
know before. E.g. to circumvent problems where the autodetection of old-style
toString() numeric fields vs. NumericField is needed. So I always specify the
NF parser explicitely on FieldCache.getLong(IR, Parser). Or is this no longer
the case?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086570#comment-13086570
]
Martijn van Groningen commented on LUCENE-3360:
---
bq. E.g. to circumvent problems where the autodetection of old-style toString()
numeric fields vs. NumericField is needed.
You mean this problem in LongValuesCreator#fillLongValues:
{code}
if( parser == null ) {
try {
parser = FieldCache.DEFAULT_LONG_PARSER;
fillLongValues( vals, reader, field );
return;
}
catch (NumberFormatException ne) {
vals.parserHashCode = null; // wipe the previous one
parser = FieldCache.NUMERIC_UTILS_LONG_PARSER;
fillLongValues( vals, reader, field );
return;
}
}
{code}
Anyway we can make these *_PARSER fields publicly available. Would the
search.cache.parsers package be a good location?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086580#comment-13086580
]
Uwe Schindler commented on LUCENE-3360:
---
bq. You mean this problem in LongValuesCreator#fillLongValues:
Yes, same for the other types!
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082132#comment-13082132
]
Shai Erera commented on LUCENE-3360:
bq. I named the per segment FieldCache interface AtomicFieldCache for now.
Perhaps SegmentFieldCache?
bq. I think that lucene.search.cache is a better place for this
AtomicFieldCache and its implementation than lucene.index package.
I agree. FieldCache is used mostly for search purposes.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch, LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079860#comment-13079860
]
Martijn van Groningen commented on LUCENE-3360:
---
Thanks Hoss - Lots of issues related to the FieldCache! I got some reading to
do :)
bq. I think that the distance between putting FieldCache in IndexReader to
allow plugging-in any Cache is very small, and does not require much
more efforts.
I like the idea of a general cache. However I think we should do very small
steps at the time. All these issues / proposals include a lot of changes and I
think we have a bigger chance to commit something if we take small steps. So we
could add the cache infrastructure to the IndexReader in a separate issue after
this issue has been resolved.
bq. (but got hung up on other things, particularly how reopen would affect this)
In this draft patch in case of a reopen / clone the new SegmentIndexReader just
gets the FieldCache instance from the previous SegmentIndexReader.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080249#comment-13080249
]
Michael McCandless commented on LUCENE-3360:
I agree we should proceed with amoeba-steps here: FieldCache has been a tar pit
in the past!!
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079279#comment-13079279
]
Martijn van Groningen commented on LUCENE-3360:
---
Most of the work will be changing the code that is using FieldCache.DEFAULT
field to use the IndexReader.getFieldCache() method.I found 92 usages of the
FieldCache.DEFAULT field in both production and test code.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 4.0
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079283#comment-13079283
]
Uwe Schindler commented on LUCENE-3360:
---
That sounds great.
We could even backport this to Lucene 3.x and simply make a backwards fake
FieldCache.DEFAULT impl that delegates to the IndexReader that is passed in to
getInts() others.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 4.0
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079286#comment-13079286
]
Uwe Schindler commented on LUCENE-3360:
---
Of course we should check the SegmentReader code to reuse FieldCache instances
on reopen, when just the deleted docs changed by reopening. Also clone should
simply reuse the fieldcache in the SegmentReader clone (that is what reopen
does in this case).
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 4.0
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079290#comment-13079290
]
Martijn van Groningen commented on LUCENE-3360:
---
Good idea. Backporting this to Lucene 3.x seems like a good plan if we make a
fake FieldCache.DEFAULT impl that delgates to IR.
Yes, we should reuse the fieldcache in case of a reopen. I see that
reopenSegement just instantiates a new SegmentReader instance, so we can just
pass the existing FieldCache instance to the new SegementReader instance.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079373#comment-13079373
]
Uwe Schindler commented on LUCENE-3360:
---
Tiny, nice! I most like the readerFinishedListeners that purge the cache!
I would suggest to add a new interface/abstract class for the per-Reader
FieldCaches, as we currently have the stupid extra IndexReader param in the
interface. The current FieldCacheImpl/FieldCache interface in the search
package should be removed. The new one could have same name in the index
package.
I would move the current FieldCacheImpl code to the SlowMultiReaderWrapper
(with the new interface) and leave the deprecated FieldCache/FieldCacheImpl in
search with just delegating like this, but no actual impls:
{code}
int[] FieldCacheImpl#getInts(IndexReader reader, String field) throws
IOException {
return new SlowMultiReaderWrapper(reader).getFieldCache().getInts(field);
}
{code}
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079793#comment-13079793
]
Shai Erera commented on LUCENE-3360:
Also this discussion
http://search.lucidimagination.com/search/document/d158b489c71f31d1/indexreader_cache_a_different_angle
about a general cache hooks as part of IndexReader, where FieldCache is just
one type of Cache.
I think that the distance between putting FieldCache in IndexReader to allow
plugging-in any Cache is very small, and does not require much more efforts.
For some reason though, I have a feeling that on all the issues / discussions,
we don't seem to get to a resolution about how best to do it. Is it just a
matter of putting up a patch with a proposed impl and proceed from there?
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.4, 4.0
Attachments: LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
