lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <>
Subject [jira] Updated: (LUCENE-2665) Rework FieldCache to be more flexible/general
Date Thu, 23 Sep 2010 22:35:33 GMT


Ryan McKinley updated LUCENE-2665:

    Attachment: LUCENE-2665-FieldCacheOverhaul.patch

This is a quick sketch of a more general FieldCache -- it only implements the ByteValues case,
and is implemented in a different package.

The core API looks like this:
  public <T> T get(IndexReader reader, String field, EntryCreator<T> creator)
throws IOException

and the EntryCreator looks like this:
public abstract class EntryCreator<T> implements Serializable
  public abstract T create( IndexReader reader, String field ) throws IOException;
  public abstract T validate( T entry, IndexReader reader, String field ) throws IOException;

   * Indicate if a cached cached value should be checked before usage.  
   * This is useful if an application wants to support subsequent calls
   * to the same cached object that may alter the cached object.  If
   * an application wants to avoid this (synchronized) check, it should 
   * return 'false'
   * @return 'true' if the Cache should call 'validate' before returning a cached object
  public boolean shouldValidate() {
    return true;

   * @return A key to identify valid cache entries for subsequent requests
  public Integer getCacheKey( IndexReader reader, String field )
    return new Integer(
        EntryCreator.class.hashCode() ^ field.hashCode()

For a real cleanup, I think it makes sense to move the Parser stuff to somewhere that deals
with numerics -- I don't get why that is tied to the FieldCache

Just as sketch to get us thinking....

> Rework FieldCache to be more flexible/general
> ---------------------------------------------
>                 Key: LUCENE-2665
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Ryan McKinley
>         Attachments: 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