Your problem is probably that the query _parser_ gets in there before
the input gets to the analysis chain. When you use the admin/analysis
page, it's as though the query parser has already broken the query up
and assigned it.
Add to that that wildcard queries have their own quirks when parsing
> of
>>>> schemaless. It's great for indexing stuff fast, but if it guesses wrong
>>>> you're stuck.
>>>>
>>>>
>>>> So to the original problem: I'd start over and either
>>>> 1> use the regular setup, not schemaless
>>>
om
-Original Message-
From: Alessandro Benedetti [mailto:benedetti.ale...@gmail.com]
Sent: 24 September 2015 09:23
To: solr-user@lucene.apache.org
Subject: Re: query parsing
I would focus on this :
"
5> now kick off the DIH job and look again.
Now it shows a histo
;>
>>> Okay, so maybe I'm missing something here (I'm still relatively new to
>>> Solr myself), but am I right in thinking the following is still in your
>>> solrconfig.xml file:
>>>
>>>
>>> true
>>> managed-schema
&g
make several of your field
definitions inside the schema.xml file semi-redundant?
Regards,
Geraint
Geraint Duck
Data Scientist
Toxicology and Health Sciences
Syngenta UK
Email: geraint.d...@syngenta.com
-Original Message-
From: Alessandro Benedetti [mailto:benedetti.ale...@gmail.com]
typically, the index dir is inside the data dir. Delete the index dir
and you should be good. If there is a tlog next to it, you might want to
delete that also.
If you dont have a data dir, i wonder whether you set the data dir when
creating your core or collection. Typically the instance dir and
I would focus on this :
"
> 5> now kick off the DIH job and look again.
>
Now it shows a histogram, but most of the "terms" are long -- the full
texts of (the table.column) eventlogtext.logtext, including the whitespace
(with %0A used for newline characters)... So, it appears it is not being
@lucene.apache.org
Subject: Re: query parsing
I would focus on this :
"
> 5> now kick off the DIH job and look again.
>
Now it shows a histogram, but most of the "terms" are long -- the full texts of
(the table.column) eventlogtext.logtext, including the whitespace (with %0A
use
;
> Regards,
> Geraint
>
>
> Geraint Duck
> Data Scientist
> Toxicology and Health Sciences
> Syngenta UK
> Email: geraint.d...@syngenta.com
>
>
> -Original Message-
> From: Alessandro Benedetti [mailto:benedetti.ale...@gmail.com]
> Sent: 24 S
If you go to the Analysis tool, indexing and query time , what can you see
for your "deeper" query text and your field content ?
( using the log text field ) ?
Have you verified the current tokens in the index for that field ?
I quickly went through your config files, and they look ok, but it is
Hi Mark,
Search is not coming properly becuase you have taken "ELall" field as a
text type which is not define properly.
you have to modify the schema.xml with these chance.
--
View this message in context:
Mugeesh, I believe you are on the right path and I was eager to try out
your suggestion. So my schema.xml now contains this snippet (changes
indicated by ~):
required="true" />
~ stored="true" required="true" />
required="true" />
required="true" />
~ stored="true"
m so those 2 are the queries at the minute :
1) logtext:deeper
2) logtext:*deeper*
According to your schema, the log text field is of type "text_en".
This should be completely fine.
Have you ever changed your schema on run ? without re-indexing your old
docs ?
What happens if you use your
On 9/23/2015 10:21 AM, Alessandro Benedetti wrote:
m so those 2 are the queries at the minute :
1) logtext:deeper
2) logtext:*deeper*
According to your schema, the log text field is of type "text_en".
This should be completely fine.
Have you ever changed your schema on run ? without
This is totally weird.
Don't only re-index your old docs, find the data directory and
rm -rf data (with Solr stopped) and re-index.
re: the analysis page Alessandro mentioned.
Go to the Solr admin UI (http://localhost:8983/solr). You'll
see a drop-down on the left that lets you select a core,
On 9/23/2015 12:30 PM, Erick Erickson wrote:
Then my next guess is you're not pointing at the index you think you are
when you 'rm -rf data'
Just ignore the Elall field for now I should think, although get rid of it
if you don't think you need it.
DIH should be irrelevant here.
So let's back
Then my next guess is you're not pointing at the index you think you are
when you 'rm -rf data'
Just ignore the Elall field for now I should think, although get rid of it
if you don't think you need it.
DIH should be irrelevant here.
So let's back up.
1> go ahead and "rm -fr data" (with Solr
On 9/23/2015 11:28 AM, Erick Erickson wrote:
This is totally weird.
Don't only re-index your old docs, find the data directory and
rm -rf data (with Solr stopped) and re-index.
I pretty much do that. The thing is: I don't have a data directory
anywhere! Most of my stuff is in
OK, this is bizarre. You'd have had to set up SolrCloud by specifying the
-zkRun command when you start Solr or the -zkHost; highly unlikely. On the
admin page there would be a "cloud" link on the left side, I really doubt
one's there.
You should have a data directory, it should be the parent of
q: manufacture_t:The Hershey Company^100 OR title_t:The Hershey
Company^1000
Firstly, Make sure that manufacture_t and title_t are text_general type, and
Let's use this approach instead of your approach
q=The Hershey Companyq.op=ANDqf=manufacture_t title_tdefType=edismax
--
View this
Thanks guys for a quick reply,
Adding ( ) to query values resolved the issue!
Tanya
--
View this message in context:
http://lucene.472066.n3.nabble.com/Query-parsing-difference-between-Analysis-and-parsedquery-toString-output-tp4164851p4164912.html
Sent from the Solr - User mailing list
This trips _everybody_ up. Analysis doesn't happen until things get
through the query parser. So,
let's assume your query is
q=manufacture_t:The Hershey Company^100 OR title_t:The Hershey
Company^1000
The problem is that the query _parser_ doesn't understand that
your intent is that the hershey
It should be easy to extend ExtendedDismaxQParser and do your
pre-processing in the parse() method before calling edismax's parse. Or
maybe you could change the way EDismax is splitting the input query into
clauses by extending the splitIntoClauses method?
Tomás
On Wed, Mar 6, 2013 at 6:37 AM,
Hi,
I am trying to do something similar:-
Eg.
Input: (name:John AND name:Doe)
Output: ((firstName:John OR lastName:John) AND (firstName:John OR
lastName:John))
How can I extract the fields, change them and repackage the query?
Thanks,
Balaji
--
View this message in context:
2012/4/24 Mindaugas Žakšauskas min...@gmail.com:
Hi,
I maintain a distributed system which Solr is part of. The data which
is kept is Solr is permissioned and permissions are currently
implemented by taking the original user query, adding certain bits to
it which would make it return less
On Tue, Apr 24, 2012 at 3:27 PM, Benson Margulies bimargul...@gmail.com wrote:
I'm about to try out a contribution for serializing queries in
Javascript using Jackson. I've previously done this by serializing my
own data structure and putting the JSON into a custom query parameter.
Thanks for
In general, query parsing is such a small fraction of the total time that,
almost no matter how complex, it's not worth worrying about. To see
this, attach debugQuery=on to your query and look at the timings
in the pepare and process portions of the response. I'd be
very sure that it was a
Hi Erick,
Thanks for looking into this and for the tips you've sent.
I am leaning towards custom query component at the moment, the primary
reason for it would be to be able to squeeze the amount of data that
is sent over to Solr. A single round trip within the same datacenter
is worth around
If you're assembling an fq clause, this is all done or you, although
you need to take some care to form the fq clause _exactly_
the same way each time. Think of the filterCache as a key/value
map where the key is the raw fq text and the value is the docs
satisfying that query.
So fq=acl:(a OR a)
Do you use stop word removal on text field?
Dmitry
On Tue, Jun 14, 2011 at 9:18 PM, Andrea Eakin
andrea.ea...@systemsbiology.org wrote:
I am trying to do the following type of query:
+text:(was wasp) +pub_date_year:[1991 TO 2011]
When I turn debugQuery=on I find that the parsedquery is
Hi,
I have explored DisMaxRequestHandler. It could serve for some
of my purposes but not all.
1) It seems we have to decide that alternative field list beforehand
and declare them in the config.xml . But the field list for which
synonyms are to be considered is not definite ( at least in the
Hi,
I have explored
DisMaxRequestHandler. It could serve for some
of my purposes but not all.
1) It seems we have to decide that alternative field list
beforehand
and declare them in the config.xml . But the field list for
which
synonyms are to be considered is not definite ( at
Hello,
Thanks. This would absolutely serve. I thought of doing it in
queryparser part which I mentioned in first mail. But if the query is
a complex one, then it would become a bit complicated. Thats why I
wanted to know whether there is any other way which is similar to the
second point
Hello All,
I have been
trying to find out the right place to parse
the query submitted. To be brief, I need to expand the
query. For
example.. let the query be
city:paris
then I would like to expand the query as .. follows
city:paris OR place:paris OR town:paris .
Sorry to all, there was a terrible bug in my code.
I should have checked whether the query was changed by
(q.toString().equals(newQuery.toString()) instead of (q != newQuery)!
Hana wrote:
Hi
I need a help with boolean queries in my custom RequestHandler. The
purpose of the handler
On Mon, 20 Oct 2008 06:21:06 -0700 (PDT)
Sunil Sarje [EMAIL PROTECTED] wrote:
I am working with nightly build of Oct 17, 2008 and found the issue that
something wrong with LuceneQParserPlugin; It takes + as OR
Sunil, please do not hijack the thread :
Solr/Lucene QueryParser returns a TermQuery for phrases that end up
only as a single term. This could happen, for example, if it was
using Solr's string field type (which has effectively no analyzer).
I'd guess that you'd want to re-analyze TermQuery's? (though that
sound problematic for
@lucene.apache.org
Subject: Re: query parsing
Solr/Lucene QueryParser returns a TermQuery for phrases
that end up only as a single term. This could happen, for
example, if it was using Solr's string field type (which
has effectively no analyzer).
I'd guess that you'd want to re-analyze
I should have Googled better. It seems that my question has been asked
and answered already, and not just once:
http://www.nabble.com/Using-wildcard-with-accented-words-tf4673239.html
http://groups.google.com/group/acts_as_solr/browse_thread/thread/42920dc2dcc5fa88
On Nov 28, 2007 9:42 AM,
: I should have Googled better. It seems that my question has been asked
: and answered already, and not just once:
right, wildcard and prefix queries aren't analyzed by the query
parser (there's more on the why of this in the Lucene-Java FAQ).
To clarify one other part of your question
:
40 matches
Mail list logo
