lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2665) Rework FieldCache to be more flexible/general
Date Sun, 26 Sep 2010 16:46:33 GMT


Michael McCandless commented on LUCENE-2665:

Awesome -- this patch moves the cache into the reader!  Finally :)

Should we make the cache member of ReaderCache somehow accessible?
This way apps can purge individual entries if they want?

Maybe name this ReaderValuesCache?  Like we cache other stuff (norms,
deleted docs) in readers...

I think composite readers (Multi/DirReader) should throw UOE if you
try to get their cache; eg this is what flex APIs do as well.
Instead, the app should wrap the composite reader with a
SlowMultiReaderWrapper (or their own IndexReader impl that hides the
sequential sub readers)?

This way, creating insanity is still "possible", but, it won't be done
by accident, ie you really know what you are getting into.  If we do
that then I think we don't need insanity checking anymore (because you
made a clear choice to load vlaues @ the composite reader level).

> Rework FieldCache to be more flexible/general
> ---------------------------------------------
>                 Key: LUCENE-2665
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Ryan McKinley
>         Attachments: LUCENE-2665-FieldCacheOverhaul.patch, LUCENE-2665-FieldCacheOverhaul.patch
> The existing FieldCache implementation is very rigid and does not allow much flexibility.
 In trying to implement simple features, it points to much larger structural problems.
> This patch aims to take a fresh approach to how we work with the FieldCache.

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

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

View raw message