I was noticing when I was looking this up in LIA yesterday a mention was made that when using a field list to return just some of the stored fields, that it still takes time to seek over the fields you don't want. So, if it has this strict guarantee about order, could a user potentially optimize this by always adding short metadata fields to a document first and then longer content fields at the end?
James Dyer E-Commerce Systems Ingram Content Group (615) 213-4311 -----Original Message----- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Tuesday, December 18, 2012 7:25 PM To: solr-user@lucene.apache.org Subject: Re: "order" question on solr multi value field I agree with James. Actually lucene tests will fail if a codec violates this. Actually it goes much deeper than this. From the lucene apis, when you call IndexReader.document() with your storedfieldVisitor, it must visit the fields in the original order added. so even if you do: add("title", "title value 1"); add("body", "body value"); add("title", "title value 2"); Currently stored fields must be returned in exactly this order: title1, then body, then title2. This is pretty annoying :) I don't think its truly necessary to maintain that crazy guarantee, but I'm pretty sure something tests it somewhere. In my opinion its too restrictive and prevents useful optimizations. But in my opinion, title1 should always come back before title2 in the order you added them just like today. On Tue, Dec 18, 2012 at 10:54 AM, Dyer, James <james.d...@ingramcontent.com> wrote: > I would say such a guarantee is implied by the javadoc to > Analyzer#getPositionIncrementGap . It says this value is an "increment" to > be "added to the next token emitted from tokenStream." > > http://lucene.apache.org/core/4_0_0-ALPHA/core/org/apache/lucene/analysis/Analyzer.html#getPositionIncrementGap%28java.lang.String%29 > > Also compare unofficial documentation such as Lucene In Action 2nd ed, > section 4.7.1: "Lucene logically appends the tokens...sequentially." > > Having multi-valued fields stay in the order in which they were added to the > Document is a guarantee that many many users depend on. > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Jack Krupansky [mailto:j...@basetechnology.com] > Sent: Tuesday, December 18, 2012 9:30 AM > To: solr-user@lucene.apache.org > Subject: Re: "order" question on solr multi value field > > If there is no "official" guarantee in the Javadoc for the code then there > is no official guarantee. Period. If somebody wants an official, contractual > guarantee, a Jira should be filed to do so. To put it simple, are the values > a "list" or a "set"? > > -- Jack Krupansky > > -----Original Message----- > From: Erik Hatcher > Sent: Tuesday, December 18, 2012 9:40 AM > To: solr-user@lucene.apache.org > Cc: solr-user@lucene.apache.org > Subject: Re: "order" question on solr multi value field > > I don't know of an "official" guarantee of maintaining order but it's > definitely guaranteed an relied upon to retain order. Many will scream if > this changed. > > Indexed doesn't matter here because what you get back are the stored values > no matter if the field is indexed or not. > > Erik > > On Dec 18, 2012, at 3:04, hellorsanjeev <sanjeev.dhi...@3pillarglobal.com> > wrote: > >> thank you for quick response :) >> >> I also have the same observation and I too believe that there is no reason >> for Solr to reorder a multi value field. >> >> But would you stay firm on your conclusion if I say that my multi value >> field was indexed? >> >> Please note - as per my one year experience with Solr, it always returned >> the values in the insertions order irrespective of the fact that field was >> indexed or not. >> >> My main concern is because I couldn't find it documented anywhere, it >> might >> happen that in Solr 4.0 or later, they start reordering them. If they do >> then there will be a big problem for us :) >> >> >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/order-question-on-solr-multi-value-field-tp4027695p4027713.html >> Sent from the Solr - User mailing list archive at Nabble.com. > > >
