This was the solution.
Thank you!
- Original Message -
From: "Maciej Ł. PCSS"
To: solr-user@lucene.apache.org
Sent: Wednesday, February 1, 2017 7:57:05 AM
Subject: Re: Query structure
You should be able to put 'facetMetatagDatePrefix4:2015 OR
facetMetatagDatePre
You should be able to put 'facetMetatagDatePrefix4:2015 OR
facetMetatagDatePrefix4:2016' into the filtering query.
Maciej
W dniu 01.02.2017 o 13:43, KRIS MUSSHORN pisze:
I really need some guidance on this query structure issue.
I've got to get this solved today for my empl
Why not use filtering query? I mean the 'fq' param.
Regards
Maciej
W dniu 01.02.2017 o 13:43, KRIS MUSSHORN pisze:
I really need some guidance on this query structure issue.
I've got to get this solved today for my employer.
"Help me Obiwan. Your my only hope"
I really need some guidance on this query structure issue.
I've got to get this solved today for my employer.
"Help me Obiwan. Your my only hope"
K
- Original Message -
From: "KRIS MUSSHORN"
To: solr-user@lucene.apache.org
Sent: Tuesday, January 31,
I have a defaultSearchField and facetMetatagDatePrefix4 fields that are
correctly populated with values in SOLR 5.4.1.
if execute this query q=defaultSearchField:this text
I get the 7 docs that match.
Their are three docs in 2015 and one doc in 2016 per the facet counts in the
results.
If I
On 5/30/07, Daniel Einspanjer <[EMAIL PROTECTED]> wrote:
What I quickly found I could do without though was the HTTP overhead.
I implemented the EmbeddedSolr class found on the Solr wiki that let
me interact with the Solr engine directly. This is important since I'm
doing thousands of queries in
On 4/11/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Not really. The explain scores aren't normalized and I also couldn't
: find a way to get the explain data as anything other than a whitespace
: formatted text blob from Solr. Keep in mind that they need confidence
the defualt way Solr du
Yes, for good (hopefully)
or bad.
-Sean
Shridhar Venkatraman wrote on 5/7/2007, 12:37 AM:
Interesting..
Surrogates can also bring the searcher's subjectivity (opinion and
context) into it by the learning process ?
shridhar
Sean Timm wrote:
It may not be easy or even possible
withou
Interesting..
Surrogates can also bring the searcher's subjectivity (opinion and
context) into it by the learning process ?
shridhar
Sean Timm wrote:
It may not be easy or even possible without major changes, but having
global collection statistics would allow scores to be compared across
It may not be easy or even possible without major changes, but having
global collection statistics would allow scores to be compared across
searchers. To do this, the master indexes would need to be able to
communicate with each other.
An other approach to merging across searchers is describe
On 4/11/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
A custom Similaity class with simplified tf, idf, and queryNorm functions
might also help you get scores from the Explain method that are more
easily manageable since you'll have predictible query structures hard
coded into your application
I did a bit of research on the list for prior discussions of
normalized scores and such. Please forgive me if I overlooked
something relevant, but I didn't see anything exactly what I'm looking
for.
I am building a replacement for our current text matching engine that
takes a list of documents f
12 matches
Mail list logo
