[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654109#action_12654109
]
Robert Newson commented on LUCENE-831:
--------------------------------------
The conflict was easy to resolve, it was just an FYI, I appreciate trunk
changes rapidly. I was just wondering if a feature branch would make
synchronization easier.
Some meta-task to combine or track these things would be great. I hit the
problem that LUCENE-1478 describes. I'd previously indexed numeric values with
NumberTools, which gives String-based sorting, the most memory-intensive one.
It seems with this field cache approach and the recent FieldCacheRangeFilter on
trunk, that Lucene has a robust and coherent answer to performing efficient
sorting and range filtering for float, double, short, int and long values,
perhaps it's time to enhance Document. That might cut down the size of the API,
which in turn makes it easy to test and tune. Document could preclude
tokenization for such fields, I suspect I'm not the only one to build a
type-safe replacement to Document.
For what it's worth, I'm currently indexed longs using String.format("%019d")
and treating dates as longs (getTime()) coupled with a long[] version of
FieldCacheRangeFilter. It achieves a similar goal to this task, the long[] used
for sorting is the same as for range filtering.
> 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]
