"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: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
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.
