You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2009/08/04 23:34:14 UTC
[jira] Created: (SOLR-1334) SortableXXXField could use native
FieldCache for sorting
SortableXXXField could use native FieldCache for sorting
--------------------------------------------------------
Key: SOLR-1334
URL: https://issues.apache.org/jira/browse/SOLR-1334
Project: Solr
Issue Type: Improvement
Reporter: Uwe Schindler
When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
The same parsers could be used to create ValueSources for these types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1334) SortableXXXField could use native
FieldCache for sorting
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739371#action_12739371 ]
Uwe Schindler commented on SOLR-1334:
-------------------------------------
Ok, so it should stay as it is.
The problem with NULL values in the FieldCache is a pain, I had this problem also in FieldCacheRangeFilter. Maybe in the complete overhaul task there should be some OpenBitSet/DocIdSet in parallel to the native arrays, that marks all valid values. E.g. it could be handled like a normal cache for a specific field and could be retrieved by FieldCache.getValidValues() or something like that. The bitset is build parallel to the uninversion. If the field name is the same, the valid values are also the same (not related to data type).
What do you think?
> SortableXXXField could use native FieldCache for sorting
> --------------------------------------------------------
>
> Key: SOLR-1334
> URL: https://issues.apache.org/jira/browse/SOLR-1334
> Project: Solr
> Issue Type: Improvement
> Reporter: Uwe Schindler
>
> When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
> The same parsers could be used to create ValueSources for these types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1334) SortableXXXField could use native
FieldCache for sorting
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739453#action_12739453 ]
Yonik Seeley commented on SOLR-1334:
------------------------------------
Yup - that's what I had in mind... a DocIdSet that matches documents with a value.
> SortableXXXField could use native FieldCache for sorting
> --------------------------------------------------------
>
> Key: SOLR-1334
> URL: https://issues.apache.org/jira/browse/SOLR-1334
> Project: Solr
> Issue Type: Improvement
> Reporter: Uwe Schindler
>
> When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
> The same parsers could be used to create ValueSources for these types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1334) SortableXXXField could use native
FieldCache for sorting
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739205#action_12739205 ]
Yonik Seeley commented on SOLR-1334:
------------------------------------
Yeah - I decided against upgrading the Sortable* field types because it wouldn't be 100% back compatible, and we have the Trie* fields now anyway. The issue has to do with missing values - if you use native FieldCache entries, you can't tell when a document had a value or not and that breaks some stuff like StatisticsComponent, and SortMissingLastComparator.
> SortableXXXField could use native FieldCache for sorting
> --------------------------------------------------------
>
> Key: SOLR-1334
> URL: https://issues.apache.org/jira/browse/SOLR-1334
> Project: Solr
> Issue Type: Improvement
> Reporter: Uwe Schindler
>
> When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
> The same parsers could be used to create ValueSources for these types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1334) SortableXXXField could use native
FieldCache for sorting
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley resolved SOLR-1334.
--------------------------------
Resolution: Won't Fix
> SortableXXXField could use native FieldCache for sorting
> --------------------------------------------------------
>
> Key: SOLR-1334
> URL: https://issues.apache.org/jira/browse/SOLR-1334
> Project: Solr
> Issue Type: Improvement
> Reporter: Uwe Schindler
>
> When looking through the FieldTypes (esp. new Trie code), I found out that field types using org.apache.solr.util.NumberUtils use String sorting. As SortField can get a FieldCache Parser since LUCENE-1478, NumberUtils could supply FieldCache.Parser singletons (serializable singletons!) for the SortableXXXField types, and the SortField instances could use these parsers instead of STRING only SortFields.
> The same parsers could be used to create ValueSources for these types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.