[
https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555493#action_12555493
]
Stu Hood commented on SOLR-440:
-------------------------------
Thanks a lot for the explanation, I think I get it now.
That sounds like a good plan. Perhaps it could replace the DateField in Solr
2.0.
-----Original Message-----
From: "Hoss Man (JIRA)" <[EMAIL PROTECTED]>
Sent: Wednesday, January 2, 2008 7:20pm
To: [EMAIL PROTECTED]
Subject: [jira] Commented: (SOLR-440) Should use longs for internal DateField
storage
[
https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555450#action_12555450
]
Hoss Man commented on SOLR-440:
-------------------------------
>From an email reply i'm just now looking at...
{noformat}
Date: Sat, 22 Dec 2007 22:59:29 -0500 (EST)
From: Stu Hood
If sorting was working, why couldn't range queries be supported?
{noformat}
RangeQueries (or RangeFilters more specifically) require that a single in order
walk of the TermEnum from "low" to "high" include all values in the index that
are truly inclusive, and none that aren't .... Sorting works differently, the
first time a field is sorted on, all the values are walked and an
"inverted-invertedindex" (as i like to call it) FieldCache is built mapping
docIds to values.
Although .... assuming the FieldCache support for Longs supports a "LongParser"
the same way the Int and Float support does (i just checked, and it does) then
a "new SortableLongDateField" could be created which uses the same tricks as
SortableLongField to "index" values that sort lexigraphicaly and builds a
FieldCache using a long[] ... but knows how to parse/return ISO formated dates
(and do DateMath).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
> Should use longs for internal DateField storage
> -----------------------------------------------
>
> Key: SOLR-440
> URL: https://issues.apache.org/jira/browse/SOLR-440
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.2, 1.3
> Reporter: Stu Hood
>
> The current DateField implementation uses formatted Strings internally to
> store dates.
> As a user creating a schema, I assumed that using the DateField type would be
> more efficient than using an integer field to store seconds. In fact, the
> DateField type is currently significantly less efficient: ~20 extra bytes are
> required per value, and String sorting requires that all values fit in memory.
> As soon as sorting on long fields has been implemented (SOLR-324), I'd
> suggest that the date implementation be switched to use long values
> internally, representing milliseconds since the epoch in UTC. Unfortunately,
> this will cause index incompatibilities, so the schema version will need to
> be bumped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
