On Mon, Aug 16, 2010 at 5:23 PM, Steven A Rowe wrote:
> Hi Robert,
>
> You wrote in response to Hoss:
> > Maybe for once your argument isn't completely bogus
>
> Attacking people here is really uncalled for.
>
>
actually, he asked for it:
> you're right, we should just fix the bug that the query
Hi Robert,
You wrote in response to Hoss:
> Maybe for once your argument isn't completely bogus
Attacking people here is really uncalled for.
-1 from me.
Steve
On Mon, Aug 16, 2010 at 4:20 PM, Chris Hostetter
wrote:
>
> Even if you convince folks to make every change you think should be made
> to the Lucene QueryParser (again: please take that up in a seperate
> thread) it won't change the fact that people using analysis.jsp should
> understand the disti
: > even if you change the Lucene QUeryParser so that whitespace isn't a meta
: > character it doens't affect the underlying issue: analysis.jsp is agnostic
: > about QueryParsers.
: analysis.jsp isn't agnostic about queryparsers, its ignorant of them, and
: your default queryparser is actually a
: Maybe, separate from analysis.jsp (showing only how text is analyzed),
: Solr needs a debug page showing the steps the field's QueryParser goes
: through on a given query, to debug such tricky QueryParser/Analyzer
: interactions?
As mentioned earlier in this thread, i set out to build something
McCandless [mailto:luc...@mikemccandless.com]
Sent: Friday, August 13, 2010 5:19 AM
To: solr-user@lucene.apache.org
Subject: Re: analysis tool vs. reality
Maybe, separate from analysis.jsp (showing only how text is analyzed),
Solr needs a debug page showing the steps the field's QueryParser
Maybe, separate from analysis.jsp (showing only how text is analyzed),
Solr needs a debug page showing the steps the field's QueryParser goes
through on a given query, to debug such tricky QueryParser/Analyzer
interactions?
We could make a wrapper around the analyzer that records each text
fragmen
On Thu, Aug 12, 2010 at 8:07 PM, Chris Hostetter
wrote:
>
> : > You say it's bogus because the qp will divide on whitesapce first --
> but
> : > you're assuming you know what query parser will be used ... the "field"
> : > query parser (to name one) doesn't split on whitespace first. That's
> my
: > You say it's bogus because the qp will divide on whitesapce first -- but
: > you're assuming you know what query parser will be used ... the "field"
: > query parser (to name one) doesn't split on whitespace first. That's my
: > point: analysis.jsp doesn't make any assumptions about what quer
On Thu, Aug 12, 2010 at 7:55 PM, Chris Hostetter
wrote:
>
>
> You say it's bogus because the qp will divide on whitesapce first -- but
> you're assuming you know what query parser will be used ... the "field"
> query parser (to name one) doesn't split on whitespace first. That's my
> point: analys
: Furthermore, I would like to add its not just the highlight matches
: functionality that is horribly broken here, but the output of the analysis
: itself is misleading.
:
: lets say i take 'textTight' from the example, and add the following synonym:
:
: this is broken => broke
:
: the query t
is.jsp. However,
> it operates on text that you enter into the form, not on actual index
> data. Since all my documents have a unique ID, I'd like to supply an
> ID and a query, and get back the same index/query sections- using
> whats actually in the index.
>
>
> -
Furthermore, I would like to add its not just the highlight matches
functionality that is horribly broken here, but the output of the analysis
itself is misleading.
lets say i take 'textTight' from the example, and add the following synonym:
this is broken => broke
the query time analysis is wro
On Wed, Aug 4, 2010 at 1:45 PM, Chris Hostetter wrote:
>
> it really only attempts to identify when there is overlap between
> analaysis at query time and at indexing time so you can easily spot when
> one analyzer or the other "breaks" things so that they no longer line up
> (or when it "fiexes"
: I think I agree with Justin here, I think the way analysis tool highlights
: 'matches' is extremely misleading, especially considering it completely
: ignores queryparsing.
it really only attempts to identify when there is overlap between
analaysis at query time and at indexing time so you can
On Wed, Aug 4, 2010 at 7:52 PM, Robert Muir wrote:
> I think I agree with Justin here, I think the way analysis tool highlights
> 'matches' is extremely misleading, especially considering it completely
> ignores queryparsing.
>
> it would be better if it put your text in a memoryindex and actuall
into the form, not on actual index
> data. Since all my documents have a unique ID, I'd like to supply an
> ID and a query, and get back the same index/query sections- using
> whats actually in the index.
>
>
> ------ Forwarded message --
> From: Erik Hatch
dDelimterFilterFactory for title fieldtype. Now, in the analysis
tool "ABC12" matches "ABC12". However, when doing an actual query, it
does not match.
Thank you for any help,
Justin
-- Forwarded message --
From: Erik Hatcher
To: solr-user@lucene.apache.org
Date
t
> does not match.
>
> Thank you for any help,
> Justin
>
>
> -- Forwarded message ------
> From: Erik Hatcher
> To: solr-user@lucene.apache.org
> Date: Tue, 3 Aug 2010 16:50:06 -0400
> Subject: Re: analysis tool vs. reality
> The analysis tool is me
The analysis tool is merely that, but during querying there is also a
query parser involved. Adding debugQuery=true to your request will
give you the parsed query in the response offering insight into what
might be going on. Could be lots of things, like not querying the
fields you think
20 matches
Mail list logo
