Yes, I understand that reindexing is neccesary , however for some reason I
was not able to invoke the js script from the updateprocessor, so I ended
up using Java only solution at index time.
Thanks.
On Thu, Dec 11, 2014 at 7:18 AM, Ahmet Arslan
wrote:
>
> Hi,
>
> No special steps to be taken fo
Hi,
No special steps to be taken for cloud setup. Please note that for both
solutions, re-index is mandatory.
Ahmet
On Thursday, December 11, 2014 12:15 PM, S.L wrote:
Ahmet,
Thank you , as the configurations in SolrCloud are uploaded to zookeeper ,
are there any special steps that need to
Ahmet,
Thank you , as the configurations in SolrCloud are uploaded to zookeeper ,
are there any special steps that need to be taken to make this work in
SolrCloud ?
On Wed, Dec 10, 2014 at 4:32 AM, Ahmet Arslan
wrote:
>
> Hi,
>
> Or even better, you can use your new field for tie break purposes.
Mikhail,
Thank you for confirming this , however Ahmet's proposal seems more simpler
to implement to me .
On Wed, Dec 10, 2014 at 5:07 AM, Mikhail Khludnev <
mkhlud...@griddynamics.com> wrote:
>
> S.L,
>
> I briefly skimmed Lucene50NormsConsumer.writeNormsField(), my conclusion
> is: if you suppl
S.L,
I briefly skimmed Lucene50NormsConsumer.writeNormsField(), my conclusion
is: if you supply own similarity, which just avoids putting float to byte
in Similarity.computeNorm(FieldInvertState), you get right this value in .
Similarity.decodeNormValue(long).
You may wonder but this is what's exa
Hi,
Or even better, you can use your new field for tie break purposes. Where scores
are identical.
e.g. sort=score desc, wordCount asc
Ahmet
On Wednesday, December 10, 2014 11:29 AM, Ahmet Arslan
wrote:
Hi,
You mean update processor factory?
Here is augmented (wordCount field added) versio
Hi,
You mean update processor factory?
Here is augmented (wordCount field added) version of your example :
doc1:
phoneName:"Details about Apple iPhone 4s - 16GB - White (Verizon)
Smartphone Factory Unlocked"
wordCount: 11
doc2:
phoneName:"Apple iPhone 4S 16GB for Net10, No Contract, White"
w
Hi Ahmet,
Is there already an implementation of the suggested work around ? Thanks.
On Tue, Dec 9, 2014 at 6:41 AM, Ahmet Arslan
wrote:
> Hi,
>
> Default length norm is not best option for differentiating very short
> documents, like product names.
> Please see :
> http://find.searchhub.org/doc
I wonder why your explains are so brief, mine looks like
0.4500489 = (MATCH) weight(text:inc in 17) [DefaultSimilarity], result of:
0.4500489 = fieldWeight in 17, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
2.880313 = idf(docFreq=8, maxDocs=59)
0.15625
Hi,
Default length norm is not best option for differentiating very short
documents, like product names.
Please see :
http://find.searchhub.org/document/b3f776512ab640ec#b3f776512ab640ec
I suggest you to create an additional integer field, that holds number of
tokens. You can populate it via u
Hi ,
Mikhail Thanks , I looked at the explain and this is what I see for the two
different documents in questions, they have identical scores even though
the document 2 has a shorter productName field, I do not see any lenghtNorm
related information in the explain.
Also I am not exactly clear o
It's worth to look into to check particular scoring values. But
for most suspect is the reducing precision when float norms are stored in
byte vals. See javadoc for DefaultSimilarity.encodeNormValue(float)
On Mon, Dec 8, 2014 at 5:49 PM, S.L wrote:
> I have two documents doc1 and doc2 and each
I have two documents doc1 and doc2 and each one of those has a field called
phoneName.
doc1:phoneName:"Details about Apple iPhone 4s - 16GB - White (Verizon)
Smartphone Factory Unlocked"
doc2:phoneName:"Apple iPhone 4S 16GB for Net10, No Contract, White"
Here if I search for
q=iphone+4s+16gb&qf
13 matches
Mail list logo
