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
an
> guessing wrong (again and again and again). This is the classic weakness
>>>> of
>>>> schemaless. It's great for indexing stuff fast, but if it guesses wrong
>>>> you're stuck.
>>>>
>>>>
>>>> So to the origi
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]
Sent: 24 September 2015 09:23
To: solr-user@lucene
Thu, Sep 24, 2015 at 2:02 AM, Duck Geraint (ext) GBJH <
>> geraint.d...@syngenta.com> wrote:
>>
>>> 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
&g
the following is still in your
solrconfig.xml file:
true
managed-schema
If so, wouldn't using a managed schema make several of your field
definitions inside the schema.xml file semi-redundant?
Regards,
Geraint
Geraint Duck
Data Scientist
Toxicology and Health Sciences
S
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...
3
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 histogram, but most of the "terms" are long -- the full texts of
(the table.column) eventlogtext.logtext, including the whitespace
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
tok
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
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 t
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 u
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 sto
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 /localapps/dev/E
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,
sel
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 re-inde
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 ana
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" multiValue
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:
http://lucene.472066.n3.nabble.com/query-parsing-tp423077
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 q
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 arch
"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 Company&q.op=AND&qf=manufacture_t title_t&defType=edismax
--
View thi
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 c
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:
http://lu
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) w
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 0.5
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 pr
On Tue, Apr 24, 2012 at 3:27 PM, Benson Margulies 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 your reply. Appreci
2012/4/24 Mindaugas Žakšauskas :
> 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 data in the
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
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
> 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
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
> 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:
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 handl
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 :
http://en.wikipedia.org/wiki/Thread_hi
gt; To: solr-user@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
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
: 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
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, C
40 matches
Mail list logo
