If sorting was working, why couldn't range queries be supported?
-----Original Message----- From: "Hoss Man (JIRA)" <[EMAIL PROTECTED]> Sent: Saturday, December 22, 2007 4:45pm 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#action_12554153 ] Hoss Man commented on SOLR-440: ------------------------------- using longs for millis since epoch in addition to "long" sorting might be more efficient if all you care about is strict date sorting, but "range queries" wouldn't work in that case. that plus index back compatibility are reason enough to leave String as the internal representation of DateField ... but there is no reason we can't add a new FieldType that uses a long as the internal representation. before a lot of work is invested in this issue however, it might be a good worthwhile to revist and consider some of the previous discussions about potential changes/improvements to Solr date handling... http://www.nabble.com/dates---times-to10417533.html#a10417533 > 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.
