lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood" <>
Subject RE: [jira] Commented: (SOLR-440) Should use longs for internal DateField storage
Date Sun, 23 Dec 2007 03:59:36 GMT
If sorting was working, why couldn't range queries be supported?

-----Original Message-----
From: "Hoss Man (JIRA)" <>
Sent: Saturday, December 22, 2007 4:45pm
Subject: [jira] Commented: (SOLR-440) Should use longs for internal DateField storage


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...

> Should use longs for internal DateField storage
> -----------------------------------------------
>                 Key: SOLR-440
>                 URL:
>             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.

View raw message