Hi,
This is something that I am working on too.I have been trying to combine
results from 3 different tables and trying to avoid the usual SQL union
clauses.
One thing I have tried to do is watch out for common fields like, for
example, first name and last name that could be present in all tables
Hi,
I am new to this forum and would like to know if the function described
below has been developed or exists in Solr. If it does not exist, is it a
good Idea and can I contribute.
We need to index multiple documents with different formats. So we use Solr
with Tika (Solr Cell).
Question:
Can
and get the document urls) and Solr Cell (to extract
content afterwards) -- is already addressed in issue SOLR-1358 (
https://issues.apache.org/jira/browse/SOLR-1358).
Best,
Sascha
Kerwin wrote:
Hi,
I am new to this forum and would like to know if the function described
below has been
Hi,
Has anyone faced this issue? If yes why is Tika 0.4 bundled with solr 1.4
.. Instead it should be Tika 0.5...
Problem:
I have a zip file with multiple files of different formats in it.
I am trying to index the zip file content with Solr 1.4 but the Autodetect
parser context is not being
you've changed something on one server and not the
other.
Best
Erick
On Wed, Apr 11, 2012 at 8:19 AM, Kerwin kerwin...@gmail.com wrote:
Hi All,
I am firing the following Solr query against installations on two
environments one on my local Windows machine and the other on Unix
(Remote
Hi eveybody,
I am migrating from solr 6.5.1 to solr 8.6.1 and am having a couple of
issues for which I need your help. There is a significant change in ranking
between Solr 6 and 8 search results which I need to fix before using Solr8
in our live environment. I noticed a couple of changes upfront
Hi,
I am upgrading from Solr 6.5.1 to solr 8.6.1 and have noticed a change in
the Edismax parser behavior which is affecting our search results. If user
operators are present in the search query, the Solr 6 behavior was to take
mm parameters from the user query string which was 0% by default if
on, Jan 18, 2021 at 1:51 PM Kerwin wrote:
> Hi eveybody,
>
> I am migrating from solr 6.5.1 to solr 8.6.1 and am having a couple of
> issues for which I need your help. There is a significant change in ranking
> between Solr 6 and 8 search results which I need to fix before using Solr8
Hi David,
Thanks for filing this issue. The classic non-weightMatcher mode works well
for us right now. Yes, we are using the POSTINGS mode for most of the
fields although explicitly mentioning it gives an error since not all
fields are indexed with offsets. So I guess the highlighter is picking
Hi,
While upgrading to Solr 8 from 6 the Unified highlighter begins to have
performance issues going from approximately 100ms to more than 4 seconds
with 76 fields in the hl.q and hl.fl parameters. So I played with
different options and found that the hl.q parameter needs to have any one
field
Hi David,
Thanks so much for your reply.
hl.weightMatches was indeed the culprit. After setting it to false, I am
now getting the same sub-second response as Solr 6. I am using Solr 8.6.1
(8.6.1)
Here are the tests I carried out:
hl.requireFieldMatch=true=true (2458 ms)
snippet separator char and we can now split on
it.
summary.add(field, snippet.split(SNIPPET_SEPARATOR));
}
This has not changed in Solr 8 too, which for 76 fields gives a very large
payload. So I will keep this custom code for now.
On Fri, Jan 29, 2021 at 12:28 PM Kerwin wrote
12 matches
Mail list logo
