[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654418#action_12654418
]
Robert Newson commented on LUCENE-831:
--------------------------------------
Yes, something like that. I made a Document class with an add method for each
primitive type which allowed only the sensible choices for Store and Index.
Field subclasses would achieve the same thing. A subclass per primitive type
might be excessive, they'd be 99% identical to each other. A NumericField that
could hold a single short, int, long, float, double or Date might be enough
(new NumericField(name, 99.99F, true), the final boolean toggling YES/NO for
Store, since Index is always UNANALYZED_NO_NORMS).
Adding this to FieldInfo would change the on-disk format such that it remembers
that a particular field is of a special type? That way all the places that
Lucene currently has a multiplicity of classes or constants (SortField.INT,
etc) could be eliminated, replaced by first class support in Document/Field.
A remaining question would be whether field name is sufficient for uniqueness,
I suggest it becomes fieldname+type. This also implies changes to the Query and
Filter hierarchy.
If it helps, I can post my Document class, which had helper methods for
RangeFilter and TermQuery's for each type. It's not a complicated class, you
can probably already picture it.
> Complete overhaul of FieldCache API/Implementation
> --------------------------------------------------
>
> Key: LUCENE-831
> URL: https://issues.apache.org/jira/browse/LUCENE-831
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Hoss Man
> Fix For: 3.0
>
> Attachments: fieldcache-overhaul.032208.diff,
> fieldcache-overhaul.diff, fieldcache-overhaul.diff,
> LUCENE-831.03.28.2008.diff, LUCENE-831.03.30.2008.diff,
> LUCENE-831.03.31.2008.diff, LUCENE-831.patch, LUCENE-831.patch,
> LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch
>
>
> Motivation:
> 1) Complete overhaul the API/implementation of "FieldCache" type things...
> a) eliminate global static map keyed on IndexReader (thus
> eliminating synch block between completley independent IndexReaders)
> b) allow more customization of cache management (ie: use
> expiration/replacement strategies, disk backed caches, etc)
> c) allow people to define custom cache data logic (ie: custom
> parsers, complex datatypes, etc... anything tied to a reader)
> d) allow people to inspect what's in a cache (list of CacheKeys) for
> an IndexReader so a new IndexReader can be likewise warmed.
> e) Lend support for smarter cache management if/when
> IndexReader.reopen is added (merging of cached data from subReaders).
> 2) Provide backwards compatibility to support existing FieldCache API with
> the new implementation, so there is no redundent caching as client code
> migrades to new API.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
