[
https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555679#action_12555679
]
Stu Hood commented on SOLR-440:
-------------------------------
Is there no way to make DateField backwards compatible? Perhaps with 'magic'
values, or by looking at the byte length of the field before attempting to
parse it as a long or string?
I'm probably misunderstanding how significant a difference in memory usage it
would be, but I kindof feel like I was suckered into using DateField. I have a
field (the timestamp field in the dist solrconfig.xml that defaults to NOW)
that I currently cannot sort on, because it runs instances out of memory trying
to do a string sort.
Thanks for considering it!
> 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.
