I was asking about the field definitions from the schema.
It would also be helpful to see the debug info from the query. Just add
debug=true to see how the query and params were executed by solr and how
the calculation was done for each result.
On Thu, Oct 26, 2017 at 1:33 PM ruby wrote:
> ok.
What's the analysis configuration for the object_name field and fieldType?
Perhaps the query is matching your catch-all field, but not the object_name
field, and therefore the pf boost never happens.
On Thu, Oct 26, 2017 at 8:55 AM ruby wrote:
> I'm noticing in my following query bq= is takin
Can you provide the fieldType definition for text_fr?
Also, when you use the Analysis page in the admin UI, what tokens are
generated during indexing for FRaoo using the text_fr fieldType?
On Tue, Sep 19, 2017 at 12:01 PM Sascha Tuschinski
wrote:
> Hello Community,
>
> We are using a Solr Core
The closest thing to an execution plan that I know of is debug=true.That'll
show timings of some of the components
I also find it useful to add echoParams=all when troubleshooting. That'll
show every param solr is using for the request, including params set in
solrconfig.xml and not passed in the r
gt; you'll likely get better performance by putting them _each_ in an fq
> > E.g.
> > fq=product_identifier_type:DOTCOM_OFFER
> > fq=abstract_or_primary_product_id:[* TO *]
>
>
> why is this the case? is it just better to have no logic operators in the
> filter
Suresh,
Two things I noticed.
1) If your intent is to only match records where there's something,
anything, in abstract_or_primary_product_id, you should use fieldname:[* TO
*] but that will exclude records where that field is empty/missing. If you
want to match records even if that field is empty
ion of the query and just pass
q="title-123123123-end"
* set qf=title
On Tue, Aug 29, 2017 at 10:25 AM Josh Lincoln
wrote:
> Darko,
> Can you use edismax instead?
>
> When using dismax, solr is parsing the title field as if it's a query
> term. E.g. the query s
Darko,
Can you use edismax instead?
When using dismax, solr is parsing the title field as if it's a query term.
E.g. the query seems to be interpreted as
title "title-123123123-end"
(note the lack of a colon)...which results in querying all your qf fields
for both "title" and "title-123123123-end"
I suspect Erik's right that clean=true is the problem. That's the default
in the DIH interface.
I find that when using DIH, it's best to set preImportDeleteQuery for every
entity. This safely scopes the clean variable to just that entity.
It doesn't look like the docs have examples of using preIm
I had the same issue as Vrinda and found a hacky way to limit the number of
times deltaImportQuery was executed.
As designed, solr executes *deltaQuery* to get a list of ids that need to
be indexed. For each of those it executes *deltaImportQuery*, which is
typically very similar to the full *quer
ld. E.g. will
978-3-8052* match 978-3-8052-5094-8? At the very least, partial ISBNs (e.g.
978-3-8052) would match full ISBN without needing to use the wildcard. I'm
just not sure what happens if the user includes the wildcard.
Josh
On Thu, Jan 5, 2017 at 1:41 PM Sebastian Riemer wrote:
>
All,
I have a few questions related to boosting and whether my use case makes sense
for Dismax vs. the standard parser.
I have created a gist of my field definitions and current query structure here:
https://gist.github.com/joshdcollins/0e3f24dd23c3fc6ac8e3
With the given configuration I am at
Ravi, for the hyphen issue, try setting autoGeneratePhraseQueries=true for
that fieldType (no re-index needed). As of 1.4, this defaults to false. One
word of caution, autoGeneratePhraseQueries may not work as expected for
langauges that aren't whitespace delimited. As Erick mentioned, the
Analysis
ich is very much
> standard.
>
> Hope this helps,
> Tri
>
>
> On Mar 03, 2014, at 08:52 AM, Josh wrote:
>
> In the user core there are two fields, the database core in question was
> 40, but in production environments the database core is dynamic. My time
> has been
be mitigated? Our production environment for our heavier users would see in
the range of 3200+ user cores created a day.
Thanks for the help.
Josh
On Mon, Mar 3, 2014 at 11:24 AM, Tri Cao wrote:
> Hey Josh,
>
> I am not an expert in Java performance, but I would start with dumping a
>
about my configuration that you can think might be
useful just let me know and I can provide it. We have a work around, but it
really hampers what our long term goals were for our Solr implementation.
Thanks
Josh
On Mon, Mar 3, 2014 at 9:57 AM, Greg Walters wrote:
> Josh,
>
> You&#x
Is it indexing data from over the network? (high data throughput would
increase latency) Is it a virtual machine? (Other machines causing slow
downs) Another possible option is the network card is offloading processing
onto the CPU which is introducing latency when the CPU is under load.
On Fri,
ce it with it set this
high or even higher. Right now because of how we have this implemented just
increasing it to something high just delays the problem :/
Anything else you could suggest I would really appreciate.
On Wed, Feb 26, 2014 at 3:19 PM, Tim Potter wrote:
> Hi Josh,
>
> T
We are using the Bitnami version of Solr 4.6.0-1 on a 64bit windows
installation with 64bit Java 1.7U51 and we are seeing consistent issues
with PermGen exceptions. We have the permgen configured to be 512MB.
Bitnami ships with a 32bit version of Java for windows and we are replacing
it with a 64bi
what if you add your country field to qf with a strong boost? the search
experience would be slightly different than if you filter on country, but
maybe still good enough for your users and certainly simpler to implement
and maintain. You'd likely only want exact matches. Assuming you are using
edi
Have you tried adding autoGeneratePhraseQueries=true to the fieldType
without changing the index analysis behavior.
This works at querytime only, and will convert 12-34 to "12 34", as if the
user entered the query as a phrase. This gives the expected behavior as
long as the tokenization is the sam
38
Cached try #3 -> Total execution time: 36
Cached try #4 -> Total execution time: 35
Cached try #5 -> Total execution time: 135
Cached try #6 -> Total execution time: 31
Cached try #7 -> Total execution time: 36
Cached try #8 -> Total execution time: 30
Cached try #9 -> Total execution time: 29
Cached try #10 -> Total execution time: 28
Thanks,
Josh
t; Can you do this data in CSV format? There is a CSV reader in the DIH.
> The SEP was not intended to read from files, since there are already
> better tools that do that.
>
> Lance
>
>
> On 10/14/2013 04:44 PM, Josh Lincoln wrote:
>
>> Shawn, I'm able to read in a
PM, Lance Norskog wrote:
> On 10/13/2013 10:02 AM, Shawn Heisey wrote:
>
>> On 10/13/2013 10:16 AM, Josh Lincoln wrote:
>>
>>> I have a large solr response in xml format and would like to import it
>>> into
>>> a new solr collection. I'm able to
I have a large solr response in xml format and would like to import it into
a new solr collection. I'm able to use DIH with solrEntityProcessor, but
only if I first truncate the file to a small subset of the records. I was
hoping to set stream="true" to handle the full file, but I still get an out
Hello Wiki Admins,
I have been using Solr for a few years now and I would like to
contribute back by making minor changes and clarifications to the wiki
documentation.
Wiki User Name : JoshLincoln
Thanks
Okay, thanks for the help guys... I *think* that this can be resolved by
kicking off the delta and passing optimize=false since the default was true in
3.3.
I'll post back if I see the issue pop back up.
JT
On Wednesday, November 7, 2012 at 1:34 PM, Josh Turmel wrote:
> Here's
Here's what we have set in our data-config.xml
Thanks,
Josh Turmel
On Wednesday, November 7, 2012 at 1:00 PM, Shawn Heisey wrote:
> On 11/7/2012 10:55 AM, Otis Gospodnetic wrote:
> > Hi Shawn,
> >
> > It the last part really correct? Optimization should be do
Running Solr 3.3
We're running into issues where deleting individual documents (by ID) will
timeout but it only seems to happen when our hourly delta index is being
ran to pull in new documents, is there a way to work around this?
Thank you,
Josh
x27;t doable yet?
Please note that I don't want to query the dynamic fields, I just need them
returned in the search results. Using fl=myDynamicField_* doesn't seem to
work.
Many Thanks!
Josh
All -
We're using DIH to import flat xml files. We're getting Heap memory
exceptions due to the file size. Is there any way to force DIH to do a
streaming parse rather than a DOM parse? I really don't want to chunk my
files up or increase the heap size.
Many Thanks!
Josh
On Sep 13, 2011, at 5:05 PM, Jamie Johnson wrote:
> I know this isn't a solr specific question but I was wondering what
> folks do in regards to managing the machines in their solr cluster?
> Are there any recommendations for how to start/stop/manage these
> machines? Any suggestions would be app
On Sep 13, 2011, at 8:37 AM, Jason Toy wrote:
> I had queries breaking on me when there were spaces in the text I was
> searching for. Originally I had :
>
> fq=state_s:New York
> and that would break, I found a work around by using:
>
> fq={!raw f=state_s}New York
>
>
> My problem now is doin
Is there a suggested way to copy data in fields to additional fields that will
only be in a different core? Obviously I could index the data separately and I
could build that into my current indexing process but I'm curious if there
might be an easier, more automated way.
Thanks!
josh
Hi,
I would like to do something similar to Google, in that for my list of hits,
I would like to grab the surrounding text around my query term so I can
include that in my search results. What's the easiest way to do this?
Thanks,
Josh
Hi,
I'm having trouble figuring out how to map the tika metadata fields to my
own solr schema document fields. I guess the first hurdle I need to
overcome, is where can I find a list of the Tika PDF metadata fields that
are available for mapping?
Thanks,
Josh
36 matches
Mail list logo
