Even microseconds may not be enough on some really good, fast machine. Dennis Gearon
Signature Warning ---------------- It is always a good idea to learn from your own mistakes. It is usually a better idea to learn from others’ mistakes, so you do not have to make them yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' EARTH has a Right To Life, otherwise we all die. --- On Sun, 10/31/10, Toke Eskildsen <t...@statsbiblioteket.dk> wrote: > From: Toke Eskildsen <t...@statsbiblioteket.dk> > Subject: RE: Ensuring stable timestamp ordering > To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> > Date: Sunday, October 31, 2010, 8:33 AM > 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.
