[
https://issues.apache.org/jira/browse/LUCENE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653298#action_12653298
]
Uwe Schindler commented on LUCENE-1470:
---------------------------------------
Yes, I will open an issue! Maybe I maybe create a first patch after looking
into the problem.
bq. This seems OK for now? Can you open an issue? Retro-fitting a
super-interface would break back-compat for (admittedly very advanced) existing
Parser instances external to Lucene, right?
I am not sure, but I think its better to leave it as now. On the other hand, if
we just have a "marker" super-interface, it should be backwards compatible,
because the new super-interface is new and existing code would only use the
existing interfaces. New methods are not added by the super interface, so code
would be source and binary compatible (as it only references the existing
interfaces). I think we had this discussion some time in the past in another
issue (Fieldable???), but this was another problem.
bq. Yeah. But if we open the new issue (to allow external FieldCache parsers to
be used when sorting) then one could parse to long directly from a TrieUtil
encoded Date field, right?
Correct. As soon as this works, I would simply add as "extra bonus"
o.a.l.search.trie.TrieSortField, that automatically supplys a correct parser
for easy usage. Date, Double and Long trie fields can always be sorted as longs
without knowing the correct meaning (because the trie format was designed like
so).
Currently my code would just sort the trie encoded fields using
SortField.STRING, but this resource expensive (butI have no example currently
running, as it was not needed for panFMP/PANGAEA and other projects).
> Add TrieRangeQuery to contrib
> -----------------------------
>
> Key: LUCENE-1470
> URL: https://issues.apache.org/jira/browse/LUCENE-1470
> Project: Lucene - Java
> Issue Type: New Feature
> Components: contrib/*
> Affects Versions: 2.4
> Reporter: Uwe Schindler
> Assignee: Michael McCandless
> Fix For: 2.9
>
> Attachments: fixbuild-LUCENE-1470.patch, fixbuild-LUCENE-1470.patch,
> LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch,
> LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch
>
>
> According to the thread in java-dev
> (http://www.gossamer-threads.com/lists/lucene/java-dev/67807 and
> http://www.gossamer-threads.com/lists/lucene/java-dev/67839), I want to
> include my fast numerical range query implementation into lucene
> contrib-queries.
> I implemented (based on RangeFilter) another approach for faster
> RangeQueries, based on longs stored in index in a special format.
> The idea behind this is to store the longs in different precision in index
> and partition the query range in such a way, that the outer boundaries are
> search using terms from the highest precision, but the center of the search
> Range with lower precision. The implementation stores the longs in 8
> different precisions (using a class called TrieUtils). It also has support
> for Doubles, using the IEEE 754 floating-point "double format" bit layout
> with some bit mappings to make them binary sortable. The approach is used in
> rather big indexes, query times are even on low performance desktop
> computers <<100 ms (!) for very big ranges on indexes with 500000 docs.
> I called this RangeQuery variant and format "TrieRangeRange" query because
> the idea looks like the well-known Trie structures (but it is not identical
> to real tries, but algorithms are related to it).
--
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]
