What are the actual values in your index? I'm wondering if they all get the same values somehow, perhaps due to the granularity of your dates? And (and I'm really grasping at straws here) your <commit> is causing enough delay to have time intervals be greater than your granularity.
Unfortunately, that doesn't make much sense either. If you sort on a field, the tiebreaker should be the document ID order absent secondary sorts... So, can you post the results of adding &debugQuery=on to your URL? Also, use the schema browser from the admin page to see what you actually have in your index..... Not much help, but the best I can do this evening. Erick On Thu, Oct 28, 2010 at 9:58 PM, Michael Sokolov <soko...@ifactory.com>wrote: > (Sorry - fumble finger sent too soon.) > > > My confusion stems from the fact that in my test I insert a number of > documents, and then retrieve them ordered by timestamp, and they don't come > back in the same order they were inserted (the order seems random), unless > I > commit after each insert. > > Is that expected? I could create my own timestamp values easily enough, > but > would just as soon not do so if I could use a pre-existing feature that > seems tailor-made. > > -Mike > > > -----Original Message----- > > From: Michael Sokolov [mailto:soko...@ifactory.com] > > Sent: Thursday, October 28, 2010 9:55 PM > > To: 'solr-user@lucene.apache.org' > > Subject: Ensuring stable timestamp ordering > > > > I'm curious what if any guarantees there are regarding the > > "timestamp" field that's defined in the sample solr > > schema.xml. Just for completeness, the definition is: > > > > <!-- Uncommenting the following will create a "timestamp" field using > a default value of "NOW" to indicate when each document was indexed. > --> > <field name="timestamp" type="date" indexed="true" stored="true" > default="NOW" multiValued="false"/> > >
