Hi Bryan,
Thanks for your quick response.
I am trying to ingest data into SolrCloud, Hence I will not have any solr
query. Will it be right approach to use QueryRequest to index data ? Do I
need to put any dummy solrQuery instead ?
--
View this message in context:
http://lucene.472066.n3.nab
All,
I finally got around to documenting Apache Tika's MockParser[1]. As of Tika
1.15 (unreleased), add tika-core-tests.jar to your class path, and you can
simulate:
1. Regular catchable exceptions
2. OOMs
3. Permanent hangs
This will allow you to determine if your ingest framework is robust
Tim,
it's a awesome feature for downstream projects' integration tests. Thanks
for implementing it!
чт, 16 февр. 2017 г. в 16:17, Allison, Timothy B. :
> All,
>
> I finally got around to documenting Apache Tika's MockParser[1]. As of
> Tika 1.15 (unreleased), add tika-core-tests.jar to your cla
Excellent, Tim! Thank you for all your great work on Apache Tika!
2017-02-16 11:23 GMT-02:00 Konstantin Gribov :
> Tim,
>
> it's a awesome feature for downstream projects' integration tests. Thanks
> for implementing it!
>
> чт, 16 февр. 2017 г. в 16:17, Allison, Timothy B. :
>
> > All,
> >
> > I
Hello,
The QueryRequest was just an example, it will work with any request
that extends SolrRequest.
How are you indexing your documents?
I am going to assume you are doing something like this:
SolrClient client = ...
client.add(solrInputDocument);
Behind the scenes this will do something like
++1 awesome job
++
Chris Mattmann, Ph.D.
Principal Data Scientist, Engineering Administrative Office (3010)
Manager, NSF & Open Source Projects Formulation and Development Offices (8212)
NASA Jet Propulsion Laboratory Pasadena
Hey,
The other alternative would be to implement a HttpClientConfigurer which
can perform preemptive basic authentication (just the same way SolrRequest
is sending the credentials). The code is available in the branch_6x here,
https://github.com/apache/lucene-solr/blob/1bfa057d5c9d89b116031baa749
Hi,
I'm doing a quite complex boost function for my search and I'm wondering
what method has better performance.
- Single *bf* function with a *sum()* chain.
*For example*: bf: sum(sum(sum(A,B),C),D)
- Multiple bf parameters (which internally does the same sum chain).
*For example*: bf:
: partial update or a complete document. Under the hood a partial update
: is a complete object anyway. Using partial updates you gain a little
: bandwidth at the expense of additional stored fields.
FWIW: once SOLR-5944 lands in a released version, that won't always be
true -- atomic updates
Hi,
I have an index with a field that looks like below:
Below are some examples of version values:
"version":"2.0.5"},
{
"version":"1.10-b04"},
{
"version":"2.3.3"},
{
"version":"2.0-M5.1"},
{
"version":"0.4.0"},
{
"v
Hi,
Would like to check, is it possible to do a select of say TOP 10 items from
Solr query, and use the list of the items to do another query (Eg: JSON
Facet)?
Currently, I'm using a normal facet to retrieve the list of the TOP 10 item
from the normal faceting.
After which, I have to list out all
So basically you want faceting only on the returned result set?
I doubt that this is possible without additional queries. The issue is
that faceting and result collecting is done within one iteration, so
when some document (actually the document's internal id) is fetched as a
possible result item,
12 matches
Mail list logo