@Erick
Sorry! I chose a simple example as I wanted to reduce complexity.
In detail:
* We have distinct contents like tours, offers, events, etc which
themselves may be categorized: A tour may be a hiking tour, a
mountaineering tour, ...
* We have hundreds of customers that want to facet their sear
Thank you very much for your answer!
Beam has a compile time dependency on Solr so the user doesn't have to
provide his own. The problem would happen when a user wants to use both
Solr X version and Beam SolrIO in the same project.
As I understood it'd be the best choice to use the 8.x.y version
Michael, sorry for the confusion; I was positing a *hypothetical*
"exists()" function that doesn't currently exist, that *is* an
aggregate function, and the *does* stop early. I didn't account for
the fact that there's already an "exists()" function *query* that
behaves very differently. So yes, de
Is there a reason you can't use a bunch of solr versions and let beam users
choose at runtime?
> On Oct 30, 2020, at 4:58 AM, Piotr Szuberski
> wrote:
>
> Thank you very much for your answer!
>
> Beam has a compile time dependency on Solr so the user doesn't have to
> provide his own. The pr
I don’t think there’s anything to do what you’re asking OOB.
If all of those facet queries are _known_ to be a performance hit,
you might be able to do something custom.That would require
custom code though and I wouldn’t go there unless you can
demonstrate need.
If you issue a debug=timing you’
Srinivas,
For atomic updates, you could use add-distinct operation to avoid
duplicates -
https://lucene.apache.org/solr/guide/8_6/updating-parts-of-documents.html
This operation is available from Solr 7.3
Regards,
Munendra S N
On Thu, Oct 29, 2020 at 10:27 PM Walter Underwood
wrote:
> Since
Thanks Munendra, this will really help me. Are there any performance overhead
with this?
Thanks,
Srinivas
From: Munendra S N
Sent: 30 October 2020 19:20
To: solr-user@lucene.apache.org
Subject: Re: Avoiding duplicate entry for a multivalued field
Srinivas,
For atomic updates, you could use a
>If all of those facet queries are _known_ to be a performance hit,
you might be able to do something custom.That would require
custom code though and I wouldn’t go there unless you can
demonstrate need.
Yeah ... indeed if those facet queries are relatively static (and thus
cacheable ... even if t
add-distinct is similar to add but does contains check before adding the
value. In general, performance overhead should be minimal
Regards,
Munendra S N
On Fri, Oct 30, 2020 at 7:29 PM Srinivas Kashyap
wrote:
> Thanks Munendra, this will really help me. Are there any performance
> overhead wi
Well, it would require to maintain tests for all of the versions Beam wants
to support. For all the time Beam had SolrJ 5.5.4 as compile dependency so
it's not likely a needed feature.
On Fri, Oct 30, 2020 at 1:30 PM matthew sporleder
wrote:
> Is there a reason you can't use a bunch of solr vers
10 matches
Mail list logo
