Hmm - personally, I wouldn't want to rely on timestamps as a unique-id
generation scheme. Might we not one day want to have distributed
parallel indexing that merges lazily? Keeping timestamps unique and in
sync across multiple nodes would be a tough requirement. I would be
happy simply having NOW be more fine-grained, and this does seem like
something that would be nice to have in a fairly low level, but as I
said, if it would introduce backward-compatibility problems, it's easy
enough to create a timestamp field in the indexing feed.
Thank you for clarifying this.
-Mike
On 10/31/2010 11:33 AM, Toke Eskildsen wrote:
Lance Norskog [goks...@gmail.com] wrote:
It would be handy to have an auto-incrementing date field, so that
each document would get a unique number and the timestamp would then
be the unique ID of the document.
If someone want to implement this, I'll just note that the granilarity of Solr
dates is fixed to milliseconds:
http://lucene.apache.org/solr/api/org/apache/solr/schema/DateField.html
Using ms for unique timestamps means limiting the index rate to 1000 documents/second. That might
be okay for some applications but a serious limiter for other (our Lucene index update rate varies
between 300 and 1600 documents/second, depending on content, I am sure others have much higher
rates). One could do tricks, but it is just plain ugly to use something like "Tenths of
milliseconds since epoch", so switching to longs and nanoseconds seems to be the clean choice
if we want the timestamps to be "true" timestamps and not just a unique integer-ID
generator.
