Stick a javadoc patch in JIRA Jack? Otis -- SOLR Performance Monitoring - http://sematext.com/spm On Dec 18, 2012 2:23 PM, "Jack Krupansky" <j...@basetechnology.com> wrote:
> Yeah, and this is why I want it to be explicit. > > -- Jack Krupansky > > -----Original Message----- From: Dyer, James > Sent: Tuesday, December 18, 2012 1:54 PM > To: solr-user@lucene.apache.org > Subject: RE: "order" question on solr multi value field > > I agree with you the documentation should be more explicit. I just don't > want to give new users the impression that stored fields won't return in > the order they are added. This is the behavior and I think a lot of us > rely on that today. > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Jack Krupansky > [mailto:jack@basetechnology.**com<j...@basetechnology.com> > ] > Sent: Tuesday, December 18, 2012 11:35 AM > To: solr-user@lucene.apache.org > Subject: Re: "order" question on solr multi value field > > "A multi-valued field is the same as a single-valued field with the > positions artifically incremented" > > Yes, for the INDEX. But the concept of Lucene-level "positions" is not > relevant to STORED values. > > I'm not sure why you are confusing the two. > > A single string has guaranteed order of the characters in the string - > nobody was disputing that! > > Sure, you can argue that the contract is semi-sort-of-implied, but the > point > is that we should make it explicit. If I have time later today I'll file > the > Jira. > > -- Jack Krupansky > > -----Original Message----- From: Dyer, James > Sent: Tuesday, December 18, 2012 12:08 PM > To: solr-user@lucene.apache.org > Subject: RE: "order" question on solr multi value field > > I suppose using this same logic you can not guarantee the tokens on a > stored, single-value field would be stored in the order they arrive either, > can you? A multi-valued field is the same as a single-valued field with > the > positions artifically incremented, so what's the difference? > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Jack Krupansky > [mailto:jack@basetechnology.**com<j...@basetechnology.com> > ] > Sent: Tuesday, December 18, 2012 10:16 AM > To: solr-user@lucene.apache.org > Subject: Re: "order" question on solr multi value field > > Ah, good points, but only for the INDEXED data, not the STORED data! I > believe the concern is the stored values that are returned from a query. > Although the question does also apply to how a span query would work for a > multi-valued field. > > -- Jack Krupansky > > -----Original Message----- From: Dyer, James > Sent: Tuesday, December 18, 2012 10:54 AM > To: solr-user@lucene.apache.org > Subject: RE: "order" question on solr multi value field > > 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<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:jack@basetechnology.**com<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.dhiman@3pillarglobal.** > com <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<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. >> > > > > >
