Query Problem

[Ezequiel Calderara]

Hi all, I have the following problems.
I have this set of data (View data (Pastebin) 
)
If i do a search for: *SectionName:Programas_Home* i have no results: Returned
Data (PasteBin) 
If i do a search for: *Programas_Home* i have only 1 result: Result Returned
(Pastebin) 
if i do a search for: SectionName:Programa* i have 1 result: Result Returned
(Pastebin) 

This is my *schema*  (Pastebin) and this is my
*solrconfig* >(PasteBin)

I don't understand why when searching for "SectionName:Programas_Home" isn't
returning any results at all...

Can someone send some light on this?
-- 
__
Ezequiel.

Http://www.ironicnet.com

Shard Query Problem

[Anshul jain]

Hi,

I'm using distributed Solr with two machines.

when I query in URL: http://lca2-s5-pc04:8080/solr/select?&q=name:john
I get  and 10 documents are
shown.

when I query in URL:
http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr&q=name:john
I get  and 0 documents are
shown.

when I query in URL:
http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr,lca2-s5-pc05:8080/solr&q=name:john
 and again 0 documents are
shown.

I'm not able to figure out why it is not able to use SHARDS for querying and
return documents. Can it be a Solr-config problem??

Thanks and Cheers,
Anshul

-- 
Anshul Jain

Phrase Query Problem?

[Tod]

I have a number of fields I need to do an exact match on.  I've defined 
them as 'string' in my schema.xml.  I've noticed that I get back query 
results that don't have all of the words I'm using to search with.


For example:

q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))&start=0&indent=true&wt=json

Should, with an exact match, return only one entry but it returns five 
some of which don't have any of the fields I've specified.  I've tried 
this both with and without quotes.


What could I be doing wrong?


Thanks - Tod

Re: Query Problem

[Erick Erickson]

Ezequiel:

Nice job of including relevant details, by the way. Unfortunately I'm
puzzled too. Your SectionName is a "string" type, so it should
be placed in the index as-is. Be a bit cautious about looking at
returned results (as I see in one of your xml files) because the returned
values are the verbatim, stored field NOT what's tokenized, and the
tokenized data is what's searched..

That said, you SectionName should not be tokenized at all because
it's a string type. Take a look at the admin page, "schema browser" and
see what values for "SectionName" look (these will be the tokenized
values". They should be exactly
Programas_Name, complete with underscore, case changes, etc. Is that
the case?

Another place that might help is the admin/analysis page. Check the debug
boxes and input your steps and it'll show you what the transformations
are applied. But a quick look leaves me completely baffled.

Sorry I can't be more help
Erick

On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara wrote:

> Hi all, I have the following problems.
> I have this set of data (View data (Pastebin) <
> http://pastebin.com/jKbUhjVS>
> )
> If i do a search for: *SectionName:Programas_Home* i have no results:
> Returned
> Data (PasteBin) 
> If i do a search for: *Programas_Home* i have only 1 result: Result
> Returned
> (Pastebin) 
> if i do a search for: SectionName:Programa* i have 1 result: Result
> Returned
> (Pastebin) 
>
> This is my *schema*  (Pastebin) and this is
> my
> *solrconfig* >(PasteBin)
>
> I don't understand why when searching for "SectionName:Programas_Home"
> isn't
> returning any results at all...
>
> Can someone send some light on this?
> --
> __
> Ezequiel.
>
> Http://www.ironicnet.com
>

Re: Query Problem

[Ezequiel Calderara]

I'll check the Tokenizer to see if that's the problem.
The results of Analysis Page for "SectionName:Programas_Home"
 Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}  term
position 1 term text Programas_Home term type word source start,end 0,14
payload

So it's not having problems with that... Also in the debug you can see that
the parsed query is correct...
So i don't know where to look...

I know nothing about "Stemming" or tokenizing, but i will look if that has
anything to do.

If anyone can help me out, please do :D




On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson wrote:

> Ezequiel:
>
> Nice job of including relevant details, by the way. Unfortunately I'm
> puzzled too. Your SectionName is a "string" type, so it should
> be placed in the index as-is. Be a bit cautious about looking at
> returned results (as I see in one of your xml files) because the returned
> values are the verbatim, stored field NOT what's tokenized, and the
> tokenized data is what's searched..
>
> That said, you SectionName should not be tokenized at all because
> it's a string type. Take a look at the admin page, "schema browser" and
> see what values for "SectionName" look (these will be the tokenized
> values". They should be exactly
> Programas_Name, complete with underscore, case changes, etc. Is that
> the case?
>
> Another place that might help is the admin/analysis page. Check the debug
> boxes and input your steps and it'll show you what the transformations
> are applied. But a quick look leaves me completely baffled.
>
> Sorry I can't be more help
> Erick
>
> On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara  >wrote:
>
> > Hi all, I have the following problems.
> > I have this set of data (View data (Pastebin) <
> > http://pastebin.com/jKbUhjVS>
> > )
> > If i do a search for: *SectionName:Programas_Home* i have no results:
> > Returned
> > Data (PasteBin) 
> > If i do a search for: *Programas_Home* i have only 1 result: Result
> > Returned
> > (Pastebin) 
> > if i do a search for: SectionName:Programa* i have 1 result: Result
> > Returned
> > (Pastebin) 
> >
> > This is my *schema*  (Pastebin) and this
> is
> > my
> > *solrconfig*  ?>>(PasteBin)
>  >
> > I don't understand why when searching for "SectionName:Programas_Home"
> > isn't
> > returning any results at all...
> >
> > Can someone send some light on this?
> > --
> > __
> > Ezequiel.
> >
> > Http://www.ironicnet.com 
> >
>



-- 
__
Ezequiel.

Http://www.ironicnet.com

Re: Query Problem

[Erick Erickson]

OK, what version of Solr are you using? I can take a quick check to see
what behavior I get

Erick

On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara wrote:

> I'll check the Tokenizer to see if that's the problem.
> The results of Analysis Page for "SectionName:Programas_Home"
>  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}  term
> position 1 term text Programas_Home term type word source start,end 0,14
> payload
>
> So it's not having problems with that... Also in the debug you can see that
> the parsed query is correct...
> So i don't know where to look...
>
> I know nothing about "Stemming" or tokenizing, but i will look if that has
> anything to do.
>
> If anyone can help me out, please do :D
>
>
>
>
> On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson  >wrote:
>
> > Ezequiel:
> >
> > Nice job of including relevant details, by the way. Unfortunately I'm
> > puzzled too. Your SectionName is a "string" type, so it should
> > be placed in the index as-is. Be a bit cautious about looking at
> > returned results (as I see in one of your xml files) because the returned
> > values are the verbatim, stored field NOT what's tokenized, and the
> > tokenized data is what's searched..
> >
> > That said, you SectionName should not be tokenized at all because
> > it's a string type. Take a look at the admin page, "schema browser" and
> > see what values for "SectionName" look (these will be the tokenized
> > values". They should be exactly
> > Programas_Name, complete with underscore, case changes, etc. Is that
> > the case?
> >
> > Another place that might help is the admin/analysis page. Check the debug
> > boxes and input your steps and it'll show you what the transformations
> > are applied. But a quick look leaves me completely baffled.
> >
> > Sorry I can't be more help
> > Erick
> >
> > On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara  > >wrote:
> >
> > > Hi all, I have the following problems.
> > > I have this set of data (View data (Pastebin) <
> > > http://pastebin.com/jKbUhjVS>
> > > )
> > > If i do a search for: *SectionName:Programas_Home* i have no results:
> > > Returned
> > > Data (PasteBin) 
> > > If i do a search for: *Programas_Home* i have only 1 result: Result
> > > Returned
> > > (Pastebin) 
> > > if i do a search for: SectionName:Programa* i have 1 result: Result
> > > Returned
> > > (Pastebin) 
> > >
> > > This is my *schema*  (Pastebin) and this
> > is
> > > my
> > > *solrconfig*  > ?>>(PasteBin)
> >  >
> > > I don't understand why when searching for "SectionName:Programas_Home"
> > > isn't
> > > returning any results at all...
> > >
> > > Can someone send some light on this?
> > > --
> > > __
> > > Ezequiel.
> > >
> > > Http://www.ironicnet.com 
> > >
> >
>
>
>
> --
> __
> Ezequiel.
>
> Http://www.ironicnet.com
>

Re: Query Problem

[Ezequiel Calderara]

The jars are named like *1.4.1* . So i suppose its the version 1.4.1

Thanks!

On Thu, Dec 16, 2010 at 6:54 PM, Erick Erickson wrote:

> OK, what version of Solr are you using? I can take a quick check to see
> what behavior I get
>
> Erick
>
> On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara  >wrote:
>
> > I'll check the Tokenizer to see if that's the problem.
> > The results of Analysis Page for "SectionName:Programas_Home"
> >  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}  term
> > position 1 term text Programas_Home term type word source start,end 0,14
> > payload
> >
> > So it's not having problems with that... Also in the debug you can see
> that
> > the parsed query is correct...
> > So i don't know where to look...
> >
> > I know nothing about "Stemming" or tokenizing, but i will look if that
> has
> > anything to do.
> >
> > If anyone can help me out, please do :D
> >
> >
> >
> >
> > On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson  > >wrote:
> >
> > > Ezequiel:
> > >
> > > Nice job of including relevant details, by the way. Unfortunately I'm
> > > puzzled too. Your SectionName is a "string" type, so it should
> > > be placed in the index as-is. Be a bit cautious about looking at
> > > returned results (as I see in one of your xml files) because the
> returned
> > > values are the verbatim, stored field NOT what's tokenized, and the
> > > tokenized data is what's searched..
> > >
> > > That said, you SectionName should not be tokenized at all because
> > > it's a string type. Take a look at the admin page, "schema browser" and
> > > see what values for "SectionName" look (these will be the tokenized
> > > values". They should be exactly
> > > Programas_Name, complete with underscore, case changes, etc. Is that
> > > the case?
> > >
> > > Another place that might help is the admin/analysis page. Check the
> debug
> > > boxes and input your steps and it'll show you what the transformations
> > > are applied. But a quick look leaves me completely baffled.
> > >
> > > Sorry I can't be more help
> > > Erick
> > >
> > > On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara <
> ezech...@gmail.com
> > > >wrote:
> > >
> > > > Hi all, I have the following problems.
> > > > I have this set of data (View data (Pastebin) <
> > > > http://pastebin.com/jKbUhjVS>
> > > > )
> > > > If i do a search for: *SectionName:Programas_Home* i have no results:
> > > > Returned
> > > > Data (PasteBin) 
> > > > If i do a search for: *Programas_Home* i have only 1 result: Result
> > > > Returned
> > > > (Pastebin) 
> > > > if i do a search for: SectionName:Programa* i have 1 result: Result
> > > > Returned
> > > > (Pastebin) 
> > > >
> > > > This is my *schema*  (Pastebin) and
> this
> > > is
> > > > my
> > > > *solrconfig*  > > ?>>(PasteBin)
> > >  >
> > > > I don't understand why when searching for
> "SectionName:Programas_Home"
> > > > isn't
> > > > returning any results at all...
> > > >
> > > > Can someone send some light on this?
> > > > --
> > > > __
> > > > Ezequiel.
> > > >
> > > > Http://www.ironicnet.com  <
> http://www.ironicnet.com/>
>  > > >
> > >
> >
> >
> >
> > --
> > __
> > Ezequiel.
> >
> > Http://www.ironicnet.com 
> >
>



-- 
__
Ezequiel.

Http://www.ironicnet.com

Re: Query Problem

[Erick Erickson]

OK, it works perfectly for me on a 1.4.1 instance. I've looked over your
files a couple of times and see nothing obvious (but you'll never find
anyone better at overlooking the obvious than me!).

Tokenizing and stemming are irrelevant in this case because your
type is "string", which is an untokenizedtype so you don't need to
go there.

The way your query parses and analyzes backs this up, so you're
getting to the right schema definition.

Which may bring us to whether what's in the index is what you *think* is
in there. I'm betting not. Either you changed the schema and didn't re-index
(say changed index="false" to index="true"), you didn't commit the documents
after indexing or other such-like, or changed the field type and didn't
reindex.

So go into /solr/admin. Click on "schema browser", click on "fields".
Along
the left you should see "SectionName", click on that. That will show you the
#indexed# terms, and you should see, exactly, "Programas_Home" in there,
just
like in your returned documents. Let us know if that's in fact what you do
see. It's
possible you're being mislead by the difference between seeing the value in
a returned
document (the stored value) and what's searched on (the indexed token(s)).

And I'm assuming that some asterisks in your mails were really there for
bolding and
you are NOT doing wildcard searches for, for instance,
 *SectionName:Programas_Home*.

But we're at a point where my 1.4.1 instance produces the results you're
expecting,
at least as I understand them so I don't think it's a problem with Solr, but
some change
you've made is producing results you don't expect but are correct. Like I
said,
look at the indexed terms. If you see "Programas_Home" in the admin console
after
following the steps above, then I don't know what to suggest

Best
Erick

On Thu, Dec 16, 2010 at 5:12 PM, Ezequiel Calderara wrote:

> The jars are named like *1.4.1* . So i suppose its the version 1.4.1
>
> Thanks!
>
> On Thu, Dec 16, 2010 at 6:54 PM, Erick Erickson  >wrote:
>
> > OK, what version of Solr are you using? I can take a quick check to see
> > what behavior I get
> >
> > Erick
> >
> > On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara  > >wrote:
> >
> > > I'll check the Tokenizer to see if that's the problem.
> > > The results of Analysis Page for "SectionName:Programas_Home"
> > >  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}
>  term
> > > position 1 term text Programas_Home term type word source start,end
> 0,14
> > > payload
> > >
> > > So it's not having problems with that... Also in the debug you can see
> > that
> > > the parsed query is correct...
> > > So i don't know where to look...
> > >
> > > I know nothing about "Stemming" or tokenizing, but i will look if that
> > has
> > > anything to do.
> > >
> > > If anyone can help me out, please do :D
> > >
> > >
> > >
> > >
> > > On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson <
> erickerick...@gmail.com
> > > >wrote:
> > >
> > > > Ezequiel:
> > > >
> > > > Nice job of including relevant details, by the way. Unfortunately I'm
> > > > puzzled too. Your SectionName is a "string" type, so it should
> > > > be placed in the index as-is. Be a bit cautious about looking at
> > > > returned results (as I see in one of your xml files) because the
> > returned
> > > > values are the verbatim, stored field NOT what's tokenized, and the
> > > > tokenized data is what's searched..
> > > >
> > > > That said, you SectionName should not be tokenized at all because
> > > > it's a string type. Take a look at the admin page, "schema browser"
> and
> > > > see what values for "SectionName" look (these will be the tokenized
> > > > values". They should be exactly
> > > > Programas_Name, complete with underscore, case changes, etc. Is that
> > > > the case?
> > > >
> > > > Another place that might help is the admin/analysis page. Check the
> > debug
> > > > boxes and input your steps and it'll show you what the
> transformations
> > > > are applied. But a quick look leaves me completely baffled.
> > > >
> > > > Sorry I can't be more help
> > > > Erick
> > > >
> > > > On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara <
> > ezech...@gmail.com
> > > > >wrote:
> > > >
> > > > > Hi all, I have the following problems.
> > > > > I have this set of data (View data (Pastebin) <
> > > > > http://pastebin.com/jKbUhjVS>
> > > > > )
> > > > > If i do a search for: *SectionName:Programas_Home* i have no
> results:
> > > > > Returned
> > > > > Data (PasteBin) 
> > > > > If i do a search for: *Programas_Home* i have only 1 result: Result
> > > > > Returned
> > > > > (Pastebin) 
> > > > > if i do a search for: SectionName:Programa* i have 1 result: Result
> > > > > Returned
> > > > > (Pastebin) 
> > > > >
> > > > > This is my *schema*  (Pastebin) and
> > this
> > > > is
> > > > > my
> > > > > *solrconfig* 

Re: Query Problem

[Ezequiel Calderara]

Hi Erick, you were right.

I'm looking the source of the search result (instead of the render of
internet explorer :$) and i see this:
"Programas_Home
"

So i think that is the problem is in the SSIS process that retrieves data
from the DB and sends it to solr.
The data type in the db is VARCHAR(100)... but i'm sure that somewhere is
mapping it to CHAR(100) so it's length its always 100.

Thank you very much, i will keep you informed

Thanks



On Thu, Dec 16, 2010 at 9:38 PM, Erick Erickson wrote:

> OK, it works perfectly for me on a 1.4.1 instance. I've looked over your
> files a couple of times and see nothing obvious (but you'll never find
> anyone better at overlooking the obvious than me!).
>
> Tokenizing and stemming are irrelevant in this case because your
> type is "string", which is an untokenizedtype so you don't need to
> go there.
>
> The way your query parses and analyzes backs this up, so you're
> getting to the right schema definition.
>
> Which may bring us to whether what's in the index is what you *think* is
> in there. I'm betting not. Either you changed the schema and didn't
> re-index
> (say changed index="false" to index="true"), you didn't commit the
> documents
> after indexing or other such-like, or changed the field type and didn't
> reindex.
>
> So go into /solr/admin. Click on "schema browser", click on "fields".
> Along
> the left you should see "SectionName", click on that. That will show you
> the
> #indexed# terms, and you should see, exactly, "Programas_Home" in there,
> just
> like in your returned documents. Let us know if that's in fact what you do
> see. It's
> possible you're being mislead by the difference between seeing the value in
> a returned
> document (the stored value) and what's searched on (the indexed token(s)).
>
> And I'm assuming that some asterisks in your mails were really there for
> bolding and
> you are NOT doing wildcard searches for, for instance,
>  *SectionName:Programas_Home*.
>
> But we're at a point where my 1.4.1 instance produces the results you're
> expecting,
> at least as I understand them so I don't think it's a problem with Solr,
> but
> some change
> you've made is producing results you don't expect but are correct. Like I
> said,
> look at the indexed terms. If you see "Programas_Home" in the admin console
> after
> following the steps above, then I don't know what to suggest
>
> Best
> Erick
>
> On Thu, Dec 16, 2010 at 5:12 PM, Ezequiel Calderara  >wrote:
>
> > The jars are named like *1.4.1* . So i suppose its the version 1.4.1
> >
> > Thanks!
> >
> > On Thu, Dec 16, 2010 at 6:54 PM, Erick Erickson  > >wrote:
> >
> > > OK, what version of Solr are you using? I can take a quick check to see
> > > what behavior I get
> > >
> > > Erick
> > >
> > > On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara <
> ezech...@gmail.com
> > > >wrote:
> > >
> > > > I'll check the Tokenizer to see if that's the problem.
> > > > The results of Analysis Page for "SectionName:Programas_Home"
> > > >  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}
> >  term
> > > > position 1 term text Programas_Home term type word source start,end
> > 0,14
> > > > payload
> > > >
> > > > So it's not having problems with that... Also in the debug you can
> see
> > > that
> > > > the parsed query is correct...
> > > > So i don't know where to look...
> > > >
> > > > I know nothing about "Stemming" or tokenizing, but i will look if
> that
> > > has
> > > > anything to do.
> > > >
> > > > If anyone can help me out, please do :D
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson <
> > erickerick...@gmail.com
> > > > >wrote:
> > > >
> > > > > Ezequiel:
> > > > >
> > > > > Nice job of including relevant details, by the way. Unfortunately
> I'm
> > > > > puzzled too. Your SectionName is a "string" type, so it should
> > > > > be placed in the index as-is. Be a bit cautious about looking at
> > > > > returned results (as I see in one of your xml files) because the
> > > returned
> > > > > values are the verbatim, stored field NOT what's tokenized, and the
> > > > > tokenized data is what's searched..
> > > > >
> > > > > That said, you SectionName should not be tokenized at all because
> > > > > it's a string type. Take a look at the admin page, "schema browser"
> > and
> > > > > see what values for "SectionName" look (these will be the tokenized
> > > > > values". They should be exactly
> > > > > Programas_Name, complete with underscore, case changes, etc. Is
> that
> > > > > the case?
> > > > >
> > > > > Another place that might help is the admin/analysis page. Check the
> > > debug
> > > > > boxes and input your steps and it'll show you what the
> > transformations
> > > > > are applied. But a quick look leaves me completely baffled.
> > > > >
> > > > > Sorry I can't be more help
> > > > > Erick
> > > > >
> > > > > On Thu, Dec 16, 2010 at 2:07 PM, Ezequiel Calderara <
> > > ezech...@gmail.com
> > > > > >wr

Re: Query Problem

[Erick Erickson]

Right, I *love* problems like this... NOT

You might get some joy out of using TrimFilterFactory along with
KeywordAnalyzer,
something like this:
 >






but it depends upon what your fields are padded with

Best
Erick

On Fri, Dec 17, 2010 at 8:12 AM, Ezequiel Calderara wrote:

> Hi Erick, you were right.
>
> I'm looking the source of the search result (instead of the render of
> internet explorer :$) and i see this:
> "Programas_Home
> "
>
> So i think that is the problem is in the SSIS process that retrieves data
> from the DB and sends it to solr.
> The data type in the db is VARCHAR(100)... but i'm sure that somewhere is
> mapping it to CHAR(100) so it's length its always 100.
>
> Thank you very much, i will keep you informed
>
> Thanks
>
>
>
> On Thu, Dec 16, 2010 at 9:38 PM, Erick Erickson  >wrote:
>
> > OK, it works perfectly for me on a 1.4.1 instance. I've looked over your
> > files a couple of times and see nothing obvious (but you'll never find
> > anyone better at overlooking the obvious than me!).
> >
> > Tokenizing and stemming are irrelevant in this case because your
> > type is "string", which is an untokenizedtype so you don't need to
> > go there.
> >
> > The way your query parses and analyzes backs this up, so you're
> > getting to the right schema definition.
> >
> > Which may bring us to whether what's in the index is what you *think* is
> > in there. I'm betting not. Either you changed the schema and didn't
> > re-index
> > (say changed index="false" to index="true"), you didn't commit the
> > documents
> > after indexing or other such-like, or changed the field type and didn't
> > reindex.
> >
> > So go into /solr/admin. Click on "schema browser", click on "fields".
> > Along
> > the left you should see "SectionName", click on that. That will show you
> > the
> > #indexed# terms, and you should see, exactly, "Programas_Home" in there,
> > just
> > like in your returned documents. Let us know if that's in fact what you
> do
> > see. It's
> > possible you're being mislead by the difference between seeing the value
> in
> > a returned
> > document (the stored value) and what's searched on (the indexed
> token(s)).
> >
> > And I'm assuming that some asterisks in your mails were really there for
> > bolding and
> > you are NOT doing wildcard searches for, for instance,
> >  *SectionName:Programas_Home*.
> >
> > But we're at a point where my 1.4.1 instance produces the results you're
> > expecting,
> > at least as I understand them so I don't think it's a problem with Solr,
> > but
> > some change
> > you've made is producing results you don't expect but are correct. Like I
> > said,
> > look at the indexed terms. If you see "Programas_Home" in the admin
> console
> > after
> > following the steps above, then I don't know what to suggest
> >
> > Best
> > Erick
> >
> > On Thu, Dec 16, 2010 at 5:12 PM, Ezequiel Calderara  > >wrote:
> >
> > > The jars are named like *1.4.1* . So i suppose its the version 1.4.1
> > >
> > > Thanks!
> > >
> > > On Thu, Dec 16, 2010 at 6:54 PM, Erick Erickson <
> erickerick...@gmail.com
> > > >wrote:
> > >
> > > > OK, what version of Solr are you using? I can take a quick check to
> see
> > > > what behavior I get
> > > >
> > > > Erick
> > > >
> > > > On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara <
> > ezech...@gmail.com
> > > > >wrote:
> > > >
> > > > > I'll check the Tokenizer to see if that's the problem.
> > > > > The results of Analysis Page for "SectionName:Programas_Home"
> > > > >  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer {}
> > >  term
> > > > > position 1 term text Programas_Home term type word source start,end
> > > 0,14
> > > > > payload
> > > > >
> > > > > So it's not having problems with that... Also in the debug you can
> > see
> > > > that
> > > > > the parsed query is correct...
> > > > > So i don't know where to look...
> > > > >
> > > > > I know nothing about "Stemming" or tokenizing, but i will look if
> > that
> > > > has
> > > > > anything to do.
> > > > >
> > > > > If anyone can help me out, please do :D
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson <
> > > erickerick...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Ezequiel:
> > > > > >
> > > > > > Nice job of including relevant details, by the way. Unfortunately
> > I'm
> > > > > > puzzled too. Your SectionName is a "string" type, so it should
> > > > > > be placed in the index as-is. Be a bit cautious about looking at
> > > > > > returned results (as I see in one of your xml files) because the
> > > > returned
> > > > > > values are the verbatim, stored field NOT what's tokenized, and
> the
> > > > > > tokenized data is what's searched..
> > > > > >
> > > > > > That said, you SectionName should not be tokenized at all because
> > > > > > it's a string type. Take a look at the admin page, "schema
> browser"
> > > and
> > > > > > see what values for "SectionName" look (these will 

Re: Query Problem

[Ezequiel Calderara]

Well... finally... isn't solr problem. Isn't solr config problem.
Is Microsoft's problem:
http://flyingtriangles.blogspot.com/2006/08/workaround-to-ssis-strings-are-not.html

Thank you very much erick!! you really helped on the solution of this!


On Fri, Dec 17, 2010 at 10:52 AM, Erick Erickson wrote:

> Right, I *love* problems like this... NOT
>
> You might get some joy out of using TrimFilterFactory along with
> KeywordAnalyzer,
> something like this:
>  >
> 
> 
> 
> 
> 
>
> but it depends upon what your fields are padded with
>
> Best
> Erick
>
> On Fri, Dec 17, 2010 at 8:12 AM, Ezequiel Calderara  >wrote:
>
> > Hi Erick, you were right.
> >
> > I'm looking the source of the search result (instead of the render of
> > internet explorer :$) and i see this:
> > "Programas_Home
> > "
> >
> > So i think that is the problem is in the SSIS process that retrieves data
> > from the DB and sends it to solr.
> > The data type in the db is VARCHAR(100)... but i'm sure that somewhere is
> > mapping it to CHAR(100) so it's length its always 100.
> >
> > Thank you very much, i will keep you informed
> >
> > Thanks
> >
> >
> >
> > On Thu, Dec 16, 2010 at 9:38 PM, Erick Erickson  > >wrote:
> >
> > > OK, it works perfectly for me on a 1.4.1 instance. I've looked over
> your
> > > files a couple of times and see nothing obvious (but you'll never find
> > > anyone better at overlooking the obvious than me!).
> > >
> > > Tokenizing and stemming are irrelevant in this case because your
> > > type is "string", which is an untokenizedtype so you don't need to
> > > go there.
> > >
> > > The way your query parses and analyzes backs this up, so you're
> > > getting to the right schema definition.
> > >
> > > Which may bring us to whether what's in the index is what you *think*
> is
> > > in there. I'm betting not. Either you changed the schema and didn't
> > > re-index
> > > (say changed index="false" to index="true"), you didn't commit the
> > > documents
> > > after indexing or other such-like, or changed the field type and didn't
> > > reindex.
> > >
> > > So go into /solr/admin. Click on "schema browser", click on
> "fields".
> > > Along
> > > the left you should see "SectionName", click on that. That will show
> you
> > > the
> > > #indexed# terms, and you should see, exactly, "Programas_Home" in
> there,
> > > just
> > > like in your returned documents. Let us know if that's in fact what you
> > do
> > > see. It's
> > > possible you're being mislead by the difference between seeing the
> value
> > in
> > > a returned
> > > document (the stored value) and what's searched on (the indexed
> > token(s)).
> > >
> > > And I'm assuming that some asterisks in your mails were really there
> for
> > > bolding and
> > > you are NOT doing wildcard searches for, for instance,
> > >  *SectionName:Programas_Home*.
> > >
> > > But we're at a point where my 1.4.1 instance produces the results
> you're
> > > expecting,
> > > at least as I understand them so I don't think it's a problem with
> Solr,
> > > but
> > > some change
> > > you've made is producing results you don't expect but are correct. Like
> I
> > > said,
> > > look at the indexed terms. If you see "Programas_Home" in the admin
> > console
> > > after
> > > following the steps above, then I don't know what to suggest
> > >
> > > Best
> > > Erick
> > >
> > > On Thu, Dec 16, 2010 at 5:12 PM, Ezequiel Calderara <
> ezech...@gmail.com
> > > >wrote:
> > >
> > > > The jars are named like *1.4.1* . So i suppose its the version 1.4.1
> > > >
> > > > Thanks!
> > > >
> > > > On Thu, Dec 16, 2010 at 6:54 PM, Erick Erickson <
> > erickerick...@gmail.com
> > > > >wrote:
> > > >
> > > > > OK, what version of Solr are you using? I can take a quick check to
> > see
> > > > > what behavior I get
> > > > >
> > > > > Erick
> > > > >
> > > > > On Thu, Dec 16, 2010 at 4:44 PM, Ezequiel Calderara <
> > > ezech...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > I'll check the Tokenizer to see if that's the problem.
> > > > > > The results of Analysis Page for "SectionName:Programas_Home"
> > > > > >  Query Analyzer org.apache.solr.schema.FieldType$DefaultAnalyzer
> {}
> > > >  term
> > > > > > position 1 term text Programas_Home term type word source
> start,end
> > > > 0,14
> > > > > > payload
> > > > > >
> > > > > > So it's not having problems with that... Also in the debug you
> can
> > > see
> > > > > that
> > > > > > the parsed query is correct...
> > > > > > So i don't know where to look...
> > > > > >
> > > > > > I know nothing about "Stemming" or tokenizing, but i will look if
> > > that
> > > > > has
> > > > > > anything to do.
> > > > > >
> > > > > > If anyone can help me out, please do :D
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Dec 16, 2010 at 5:55 PM, Erick Erickson <
> > > > erickerick...@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Ezequiel:
> > > > > > >
> > > > > > > Nice job of including relevant details, by the way.

Facet query problem

[ZAROGKIKAS,GIORGOS]

Hi there 

 

I 'm a new solr user 

With some problems with facets

 

I have Index a field  like that 

9

An I get ranges between 

1 an 35

When I Use fq=A00053:[16 TO 30]

I get an results between 1 and 35 

It looks like it ignores the second number of each value in my Range 

 

How can I solve that?

 

Thanks in advance

 

 

 

 

 

Analysis / Query problem

[Wagner,Harry]

I have the following custom field defined for author names.   After indexing 
the 2 documents below the admin analysis tool looks right for field-name=au and 
field-value=Schröder, Jürgen   The highlight matching also seems right.  
However, if I search for au:Schröder, Jürgen using the admin tool I do not get 
any hits (see below).  This appears to be the case whenever there are 2 
non-ascii characters in the author name.  Searching for au:Schröder, Jurgen 
finds both of these records.  Any idea what is causing this?

 

Thanks!

harry

 


  
 

 


  



   



  008053223 
  Schröder, Jürgen,
  Gottfried Benn : Poesie u. Sozialisation /
  Includes index. 
  Benn, Gottfried,.
  Authors, German--20th century--Biography.
  831.912 
  8
  83
  831
  Special 
  137
  008053223
  schroder, jurgen$1935/gottfried benn poesie u 
sozialisation 
  1
  01
  Book
  ger 
  1978-12-31T23:59:59Z
  317004446X
  9783170044463


  1
  Schröder, Jurgen,
  Gottfried Benn : Poesie u. Sozialisation / 
  Includes index.
  Benn, Gottfried,.
  Authors, German--20th century--Biography. 
  831.912
  8
  83
  831 
  Special
  137
  008053223
  schroder, jurgen$1935/gottfried benn poesie u 
sozialisation 
  1
  01
  Book
  ger 
  1978-12-31T23:59:59Z
  317004446X
  9783170044463


 

 





0

0



on

0

au:Schröder, Jürgen

10

2.2

Query problem in Solr

[Kurt Sultana]

 Hi all,

We're using Solr to search on a Shop index and a Product index. Currently a
Shop has a field `shop_keyword` which also contains the keywords of the
products assigned to it. The shop keywords are separated by a space.
Consequently, if there is a product which has a keyword "apple" and another
which has "orange", a search for shops having `Apple AND Orange` would
return the shop for these products.

However, this is incorrect since we want that a search for shops having
`Apple AND Orange` returns shop(s) having products with both "apple" and
"orange" as keywords.

We tried solving this problem, by making shop keywords multi-valued and
assigning the keywords of every product of the shop as a new value in shop
keywords. However as was confirmed in another post
http://markmail.org/thread/xce4qyzs5367yplo#query:+page:1+mid:76eerw5yqev2aanu+state:results,
Solr does not support "all words must match in the same value of a
multi-valued field".

(Hope I explained myself well)

How can we go about this? Ideally, we shouldn't change our search
infrastructure dramatically.

Thanks!

Krt_Malta

Re: Shard Query Problem

[Chris Hostetter]

Anshul: It doesn't look like you ever got an answer to this question, did 
you ever find a solution?

I'm not very shard savy, but if the numFound is coming back non-zero, the 
best guess i have is that somewhere you are overridding the default "rows" 
param with a value of 0.

if that's not it: can you post your requestHandler configurations 
from solrconfig.xml? that might shed some light on things for people.

: Date: Thu, 19 Feb 2009 22:30:19 +0100
: From: Anshul jain
: Subject: Shard Query Problem
: 
: Hi,
: 
: I'm using distributed Solr with two machines.
: 
: when I query in URL: http://lca2-s5-pc04:8080/solr/select?&q=name:john
: I get  and 10 documents are
: shown.
: 
: when I query in URL:
: http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr&q=name:john
: I get  and 0 documents are
: shown.
: 
: when I query in URL:
: 
http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr,lca2-s5-pc05:8080/solr&q=name:john
:  and again 0 documents are
: shown.
: 
: I'm not able to figure out why it is not able to use SHARDS for querying and
: return documents. Can it be a Solr-config problem??



-Hoss

Re: Shard Query Problem

[Anshul jain]

Hi Chris,

Thanks for the reply. here are the requesthandlers from solrconfig.xml:



 
   explicit

   10
   *
   2.1

 
  




 dismax
 explicit
 0.01
 
text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
 
 
text^0.2 features^1.1 name^1.5 manu^1.4 manu_exact^1.9
 
 
ord(popularity)^0.5 recip(rord(price),1,1000,1000)^0.3
 
 
id,name,price,score
 
 
2<-1 5<-2 6<90%
 
 100
 *:*
 
 text features name
 
 0
 
 name
 regex 

  

Thanks,
Anshul


On Wed, Mar 4, 2009 at 9:50 AM, Chris Hostetter wrote:

>
> Anshul: It doesn't look like you ever got an answer to this question, did
> you ever find a solution?
>
> I'm not very shard savy, but if the numFound is coming back non-zero, the
> best guess i have is that somewhere you are overridding the default "rows"
> param with a value of 0.
>
> if that's not it: can you post your requestHandler configurations
> from solrconfig.xml? that might shed some light on things for people.
>
> : Date: Thu, 19 Feb 2009 22:30:19 +0100
> : From: Anshul jain
> : Subject: Shard Query Problem
> :
> : Hi,
> :
> : I'm using distributed Solr with two machines.
> :
> : when I query in URL: http://lca2-s5-pc04:8080/solr/select?&q=name:john
> : I get  and 10 documents
> are
> : shown.
> :
> : when I query in URL:
> :
> http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr&q=name:john
> : I get  and 0 documents
> are
> : shown.
> :
> : when I query in URL:
> :
> http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr,lca2-s5-pc05:8080/solr&q=name:john
> :  and again 0 documents
> are
> : shown.
> :
> : I'm not able to figure out why it is not able to use SHARDS for querying
> and
> : return documents. Can it be a Solr-config problem??
>
>
>
> -Hoss
>
>


-- 
Anshul Jain

Re: Shard Query Problem

[Anshul jain]

Hi,

here is the whole file, if it helps





  

${solr.abortOnConfigurationError:true}

  
  ${solr.data.dir:./solr/data}


  
   
false

10



32
2147483647
1
1000
1












single
  

  

false
32
10


2147483647
1


false
  

  
  

  
  





  1
  100







  


  

1024





   


  



true




   

   
50


200







  
 solr 0 10 
 rocks 0 10 
static newSearcher warming query from
solrconfig.xml
  




  
 fast_warm 0 10 
static firstSearcher warming query from
solrconfig.xml
  



false


2

  

  
  






   
   
   

  


  
  

 
   explicit

   10
   *
   2.1

 
  


  
  

 dismax
 explicit
 0.01
 
text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
 
 
text^0.2 features^1.1 name^1.5 manu^1.4 manu_exact^1.9
 
 
ord(popularity)^0.5 recip(rord(price),1,1000,1000)^0.3
 
 
id,name,price,score
 
 
2<-1 5<-2 6<90%
 
 100
 *:*
 
 text features name
 
 0
 
 name
 regex 

  

  
  

 dismax
 explicit
 text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0
 2<-1 5<-2 6<90%
 
 incubationdate_dt:[* TO NOW/DAY-1MONTH]^2.2



  inStock:true



  cat
  manu_exact
  price:[* TO 500]
  price:[500 TO *]

  


  

   
  

textSpell


  default
  spell
  ./spellchecker1



  jarowinkler
  spell
  
  org.apache.lucene.search.spell.JaroWinklerDistance
  ./spellchecker2




  solr.FileBasedSpellChecker
  file
  spellings.txt
  UTF-8
  ./spellcheckerFile

  

  
  

  
  false
  
  false
  
  1


  spellcheck

  

  
  

string
elevate.xml
  

  
  

  explicit


  elevator

  


  
  

  
  


  
  


  
  

  
  

  standard
  solrpingquery
  all

  

  
  

 explicit 
 true

  

  
   
   
   

 100

   

   
   

  
  70
  
  0.5
  
  [-\w ,/\n\"']{20,200}

   

   
   

 
 

   
  


  

  
  
5
  


  

  

  
  
solr


  



Thanks,
Cheers,
Anshul

On Fri, Mar 6, 2009 at 7:53 PM, Anshul jain  wrote:

> Hi Chris,
>
> Thanks for the reply. here are the requesthandlers from solrconfig.xml:
>
>
> 
> 
>  
>explicit
>
>10
>*
>2.1
>
>  
>   
>
>
> 
> 
>  dismax
>  explicit
>  0.01
>  
> text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
>  
>  
> text^0.2 features^1.1 name^1.5 manu^1.4 manu_exact^1.9
>  
>  
> ord(popularity)^0.5 recip(rord(price),1,1000,1000)^0.3
>  
>  
> id,name,price,score
>  
>  
> 2<-1 5<-2 6<90%
>  
>  100
>  *:*
>  
>
>  text features name
>  
>  0
>  
>  name
>  regex 
> 
>   
>
> Thanks,
> Anshul
>
>
>
> On Wed, Mar 4, 2009 at 9:50 AM, Chris Hostetter 
> wrote:
>
>>
>> Anshul: It doesn't look like you ever got an answer to this question, did
>> you ever find a solution?
>>
>> I'm not very shard savy, but if the numFound is coming back non-zero, the
>> best guess i have is that somewhere you are overridding the default "rows"
>> param with a value of 0.
>>
>> if that's not it: can you post your requestHandler configurations
>> from solrconfig.xml? that might shed some light on things for people.
>>
>> : Date: Thu, 19 Feb 2009 22:30:19 +0100
>> : From: Anshul jain
>> : Subject: Shard Query Problem
>> :
>> : Hi,
>> :
>> : I'm using distributed Solr with two machines.
>> :
>> : when I query in URL: http://lca2-s5-pc04:8080/solr/select?&q=name:john
>> : I get  and 10 documents
>> are
>> : shown.
>> :
>> : when I query in URL:
>> :
>> http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr&q=name:john
>> : I get  and 0 documents
>> are
>> : shown.
>> :
>> : when I query in URL:
>> :
>> http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr,lca2-s5-pc05:8080/solr&q=name:john
>> :  and again 0 documents
>> are
>> : shown.
>> :
>> : I'm not able to figure out why it is not able to use SHARDS for querying
>> and
>> : return documents. Can it be a Solr-config problem??
>>
>>
>>
>> -Hoss
>>
>>
>
>
> --
> Anshul Jain
>
>


-- 
Anshul Jain

Re: Shard Query Problem

[Chris Hostetter]

t;  text features name
: >  
: >  0
: >  
: >  name
: >  regex 
: > 
: >   
: >
: > Thanks,
: > Anshul
: >
: >
: >
: > On Wed, Mar 4, 2009 at 9:50 AM, Chris Hostetter 
wrote:
: >
: >>
: >> Anshul: It doesn't look like you ever got an answer to this question, did
: >> you ever find a solution?
: >>
: >> I'm not very shard savy, but if the numFound is coming back non-zero, the
: >> best guess i have is that somewhere you are overridding the default "rows"
: >> param with a value of 0.
: >>
: >> if that's not it: can you post your requestHandler configurations
: >> from solrconfig.xml? that might shed some light on things for people.
: >>
: >> : Date: Thu, 19 Feb 2009 22:30:19 +0100
: >> : From: Anshul jain
: >> : Subject: Shard Query Problem
: >> :
: >> : Hi,
: >> :
: >> : I'm using distributed Solr with two machines.
: >> :
: >> : when I query in URL: http://lca2-s5-pc04:8080/solr/select?&q=name:john
: >> : I get  and 10 documents
: >> are
: >> : shown.
: >> :
: >> : when I query in URL:
: >> :
: >> 
http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr&q=name:john
: >> : I get  and 0 documents
: >> are
: >> : shown.
: >> :
: >> : when I query in URL:
: >> :
: >> 
http://lca2-s5-pc04:8080/solr/select?shards=lca2-s5-pc04:8080/solr,lca2-s5-pc05:8080/solr&q=name:john
: >> :  and again 0 documents
: >> are
: >> : shown.
: >> :
: >> : I'm not able to figure out why it is not able to use SHARDS for querying
: >> and
: >> : return documents. Can it be a Solr-config problem??
: >>
: >>
: >>
: >> -Hoss
: >>
: >>
: >
: >
: > --
: > Anshul Jain
: >
: >
: 
: 
: -- 
: Anshul Jain
: 



-Hoss

Re: Phrase Query Problem?

[Ken Stanley]

On Mon, Nov 1, 2010 at 10:26 PM, Tod  wrote:

> I have a number of fields I need to do an exact match on.  I've defined
> them as 'string' in my schema.xml.  I've noticed that I get back query
> results that don't have all of the words I'm using to search with.
>
> For example:
>
>
> q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))&start=0&indent=true&wt=json
>
> Should, with an exact match, return only one entry but it returns five some
> of which don't have any of the fields I've specified.  I've tried this both
> with and without quotes.
>
> What could I be doing wrong?
>
>
> Thanks - Tod
>
>

Tod,

Without knowing your exact field definition, my first guess would be your
first boolean query; because it is not quoted, what SOLR typically does is
to transform that type of query into something like (assuming your uniqueKey
is "id"): (mykeywords:Compliance id:With id:Conduct id:Standards). If you do
(mykeywords:"Compliance+With+Conduct+Standards) you might see different
(better?) results. Otherwise, append &debugQuery=on to your URL and you can
see exactly how SOLR is parsing your query. If none of that helps, what is
your field definition in your schema.xml?

- Ken

Re: Phrase Query Problem?

[Tod]

On 11/1/2010 11:14 PM, Ken Stanley wrote:

On Mon, Nov 1, 2010 at 10:26 PM, Tod  wrote:


I have a number of fields I need to do an exact match on.  I've defined
them as 'string' in my schema.xml.  I've noticed that I get back query
results that don't have all of the words I'm using to search with.

For example:


q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))&start=0&indent=true&wt=json

Should, with an exact match, return only one entry but it returns five some
of which don't have any of the fields I've specified.  I've tried this both
with and without quotes.

What could I be doing wrong?


Thanks - Tod




Tod,

Without knowing your exact field definition, my first guess would be your
first boolean query; because it is not quoted, what SOLR typically does is
to transform that type of query into something like (assuming your uniqueKey
is "id"): (mykeywords:Compliance id:With id:Conduct id:Standards). If you do
(mykeywords:"Compliance+With+Conduct+Standards) you might see different
(better?) results. Otherwise, append&debugQuery=on to your URL and you can
see exactly how SOLR is parsing your query. If none of that helps, what is
your field definition in your schema.xml?

- Ken



The field definition is:

multiValued="true"/>


The request:

select?q=(((mykeywords:"Compliance+With+Attorney+Conduct+Standards")OR(mykeywords:All)OR(mykeywords:ALL)))&fl=mykeywords&start=0&indent=true&wt=json&debugQuery=on"

The response looks like this:

 "responseHeader":{
  "status":0,
  "QTime":8,
  "params":{
"wt":"json",
"q":"(((mykeywords:Compliance With Attorney Conduct 
Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",

"start":"0",
"indent":"true",
"fl":"mykeywords",
"debugQuery":"on"}},
 "response":{"numFound":6,"start":0,"docs":[
{
 "mykeywords":["Compliance With Attorney Conduct Standards"]},
{
 "mykeywords":["Anti-Bribery","Bribes"]},
{
 "mykeywords":["Marketing Guidelines","Marketing"]},
{},
{
 "mykeywords":["Anti-Bribery","Due Diligence"]},
{
 "mykeywords":["Anti-Bribery","AntiBribery"]}]
 },
 "debug":{
  "rawquerystring":"(((mykeywords:Compliance With Attorney Conduct 
Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",
  "querystring":"(((mykeywords:Compliance With Attorney Conduct 
Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",
  "parsedquery":"(mykeywords:Compliance text:attorney text:conduct 
text:standard) mykeywords:All mykeywords:ALL",
  "parsedquery_toString":"(mykeywords:Compliance text:attorney 
text:conduct text:standard) mykeywords:All mykeywords:ALL",

  "explain":{
...

As you mentioned, looking at the parsed query its breaking the request 
up on word boundaries rather than on the entire phrase.  The goal is to 
return only the very first entry.  Any ideas?



Thanks - Tod

Re: Phrase Query Problem?

[Erick Erickson]

That's not the response I get when I try your query, so I suspect
something's not quite right with your test...

But you could also try putting parentheses around the words, like
mykeywords:(Compliance+With+Conduct+Standards)

Best
Erick

On Tue, Nov 2, 2010 at 5:25 AM, Tod  wrote:

> On 11/1/2010 11:14 PM, Ken Stanley wrote:
>
>> On Mon, Nov 1, 2010 at 10:26 PM, Tod  wrote:
>>
>>  I have a number of fields I need to do an exact match on.  I've defined
>>> them as 'string' in my schema.xml.  I've noticed that I get back query
>>> results that don't have all of the words I'm using to search with.
>>>
>>> For example:
>>>
>>>
>>>
>>> q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))&start=0&indent=true&wt=json
>>>
>>> Should, with an exact match, return only one entry but it returns five
>>> some
>>> of which don't have any of the fields I've specified.  I've tried this
>>> both
>>> with and without quotes.
>>>
>>> What could I be doing wrong?
>>>
>>>
>>> Thanks - Tod
>>>
>>>
>>>
>> Tod,
>>
>> Without knowing your exact field definition, my first guess would be your
>> first boolean query; because it is not quoted, what SOLR typically does is
>> to transform that type of query into something like (assuming your
>> uniqueKey
>> is "id"): (mykeywords:Compliance id:With id:Conduct id:Standards). If you
>> do
>> (mykeywords:"Compliance+With+Conduct+Standards) you might see different
>> (better?) results. Otherwise, append&debugQuery=on to your URL and you can
>> see exactly how SOLR is parsing your query. If none of that helps, what is
>> your field definition in your schema.xml?
>>
>> - Ken
>>
>>
> The field definition is:
>
>  multiValued="true"/>
>
> The request:
>
>
> select?q=(((mykeywords:"Compliance+With+Attorney+Conduct+Standards")OR(mykeywords:All)OR(mykeywords:ALL)))&fl=mykeywords&start=0&indent=true&wt=json&debugQuery=on"
>
> The response looks like this:
>
>  "responseHeader":{
>  "status":0,
>  "QTime":8,
>  "params":{
>"wt":"json",
>"q":"(((mykeywords:Compliance With Attorney Conduct
> Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",
>"start":"0",
>"indent":"true",
>"fl":"mykeywords",
>"debugQuery":"on"}},
>  "response":{"numFound":6,"start":0,"docs":[
>{
> "mykeywords":["Compliance With Attorney Conduct Standards"]},
>{
> "mykeywords":["Anti-Bribery","Bribes"]},
>{
> "mykeywords":["Marketing Guidelines","Marketing"]},
>{},
>{
> "mykeywords":["Anti-Bribery","Due Diligence"]},
>{
> "mykeywords":["Anti-Bribery","AntiBribery"]}]
>  },
>  "debug":{
>  "rawquerystring":"(((mykeywords:Compliance With Attorney Conduct
> Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",
>  "querystring":"(((mykeywords:Compliance With Attorney Conduct
> Standards)OR(mykeywords:All)OR(mykeywords:ALL)))",
>  "parsedquery":"(mykeywords:Compliance text:attorney text:conduct
> text:standard) mykeywords:All mykeywords:ALL",
>  "parsedquery_toString":"(mykeywords:Compliance text:attorney text:conduct
> text:standard) mykeywords:All mykeywords:ALL",
>  "explain":{
> ...
>
> As you mentioned, looking at the parsed query its breaking the request up
> on word boundaries rather than on the entire phrase.  The goal is to return
> only the very first entry.  Any ideas?
>
>
> Thanks - Tod
>

Re: Phrase Query Problem?

[Ken Stanley]

On Tue, Nov 2, 2010 at 8:19 AM, Erick Erickson wrote:

> That's not the response I get when I try your query, so I suspect
> something's not quite right with your test...
>
> But you could also try putting parentheses around the words, like
> mykeywords:(Compliance+With+Conduct+Standards)
>
> Best
> Erick
>
>
I agree with Erick, your query string showed quotes, but your parsed query
did not. Using quotes, or parenthesis, would pretty much leave your query
alone. There is one exception that I've found: if you use a stopword
analyzer, any stop words would be converted to ? in the parsed query. So if
you absolutely need every single word to match, regardless, you cannot use a
field type that uses the stop word analyzer.

For example, I have two dynamic field definitions: df_text_* that does the
default text transformations (including stop words), and df_text_exact_*
that does nothing (field type is string). When I run the
query df_text_exact_company_name:"Bank of America" OR
df_text_company_name:"Bank of America", the following is shown as my
query/parsed query when debugQuery is on:


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:Bank of America
PhraseQuery(df_text_company_name:"bank ? america")


df_text_exact_company_name:Bank of America df_text_company_name:"bank ?
america"


The difference is subtle, but important. If I were to do
df_text_company_name:"Bank and America", I would still match "Bank of
America". These are things that you should keep in mind when you are
creating fields for your indices.

A useful tool for seeing what SOLR does to your query terms is the Analysis
tool found in the admin panel. You can do an analysis on either a specific
field, or by a field type, and you will see a breakdown by Analyzer for
either the index, query, or both of any query that you put in. This would
definitely be useful when trying to determine why SOLR might return what it
does.

- Ken

Re: Phrase Query Problem?

[Tod]

On 11/2/2010 9:21 AM, Ken Stanley wrote:

On Tue, Nov 2, 2010 at 8:19 AM, Erick Ericksonwrote:


That's not the response I get when I try your query, so I suspect
something's not quite right with your test...

But you could also try putting parentheses around the words, like
mykeywords:(Compliance+With+Conduct+Standards)

Best
Erick



I agree with Erick, your query string showed quotes, but your parsed query
did not. Using quotes, or parenthesis, would pretty much leave your query
alone. There is one exception that I've found: if you use a stopword
analyzer, any stop words would be converted to ? in the parsed query. So if
you absolutely need every single word to match, regardless, you cannot use a
field type that uses the stop word analyzer.

For example, I have two dynamic field definitions: df_text_* that does the
default text transformations (including stop words), and df_text_exact_*
that does nothing (field type is string). When I run the
query df_text_exact_company_name:"Bank of America" OR
df_text_company_name:"Bank of America", the following is shown as my
query/parsed query when debugQuery is on:


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:Bank of America
PhraseQuery(df_text_company_name:"bank ? america")


df_text_exact_company_name:Bank of America df_text_company_name:"bank ?
america"


The difference is subtle, but important. If I were to do
df_text_company_name:"Bank and America", I would still match "Bank of
America". These are things that you should keep in mind when you are
creating fields for your indices.

A useful tool for seeing what SOLR does to your query terms is the Analysis
tool found in the admin panel. You can do an analysis on either a specific
field, or by a field type, and you will see a breakdown by Analyzer for
either the index, query, or both of any query that you put in. This would
definitely be useful when trying to determine why SOLR might return what it
does.

- Ken



What it turned out to be was escaping the spaces.

q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))

became

q=(((mykeywords:Compliance\+With\+Conduct\+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))

If I tried

q=(((mykeywords:"Compliance+With+Conduct+Standards")OR(mykeywords:All)OR(mykeywords:ALL)))

... it didn't work.  Once I removed the quotes and escaped spaces it 
worked as expected.  This seems odd since I would have expected the 
quotes to have triggered a phrase query.


Thanks for your help.

- Tod

Re: Phrase Query Problem?

[Jonathan Rochkind]

Indeed something doesn't seem right about that, quotes are for phrases, 
you are right, and I get confused even thinking about what happens when 
you try to "escape" spaces like that.


I think there's something odd going on with your URI-escaping in 
general. Here's what the string should actually look like for << 
mykeywords:"Compliance With Conduct Standards" >>, when put into a URI:


mykeywords%3A%22Compliance+With+Conduct+Standards%22

You really ought to escape the colon and the double quotes too, to 
follow URI spec. If you weren't escaping the double-quotes, that could 
explain your issue.  And I seriously don't understand what putting a 
backslash in the URI accomplishes in this case, it confuses me trying to 
understand what's going on there, and personally I never like it when i 
just try random things until something I don't understand works.



Tod wrote:

On 11/2/2010 9:21 AM, Ken Stanley wrote:
  

On Tue, Nov 2, 2010 at 8:19 AM, Erick Ericksonwrote:



That's not the response I get when I try your query, so I suspect
something's not quite right with your test...

But you could also try putting parentheses around the words, like
mykeywords:(Compliance+With+Conduct+Standards)

Best
Erick


  

I agree with Erick, your query string showed quotes, but your parsed query
did not. Using quotes, or parenthesis, would pretty much leave your query
alone. There is one exception that I've found: if you use a stopword
analyzer, any stop words would be converted to ? in the parsed query. So if
you absolutely need every single word to match, regardless, you cannot use a
field type that uses the stop word analyzer.

For example, I have two dynamic field definitions: df_text_* that does the
default text transformations (including stop words), and df_text_exact_*
that does nothing (field type is string). When I run the
query df_text_exact_company_name:"Bank of America" OR
df_text_company_name:"Bank of America", the following is shown as my
query/parsed query when debugQuery is on:


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:"Bank of America" OR df_text_company_name:"Bank
of America"


df_text_exact_company_name:Bank of America
PhraseQuery(df_text_company_name:"bank ? america")


df_text_exact_company_name:Bank of America df_text_company_name:"bank ?
america"


The difference is subtle, but important. If I were to do
df_text_company_name:"Bank and America", I would still match "Bank of
America". These are things that you should keep in mind when you are
creating fields for your indices.

A useful tool for seeing what SOLR does to your query terms is the Analysis
tool found in the admin panel. You can do an analysis on either a specific
field, or by a field type, and you will see a breakdown by Analyzer for
either the index, query, or both of any query that you put in. This would
definitely be useful when trying to determine why SOLR might return what it
does.

- Ken




What it turned out to be was escaping the spaces.

q=(((mykeywords:Compliance+With+Conduct+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))

became

q=(((mykeywords:Compliance\+With\+Conduct\+Standards)OR(mykeywords:All)OR(mykeywords:ALL)))

If I tried

q=(((mykeywords:"Compliance+With+Conduct+Standards")OR(mykeywords:All)OR(mykeywords:ALL)))

... it didn't work.  Once I removed the quotes and escaped spaces it 
worked as expected.  This seems odd since I would have expected the 
quotes to have triggered a phrase query.


Thanks for your help.

- Tod
  

Re: Facet query problem

[Erik Hatcher]

I'm taking an educated guess that this field is a "string" field.  In  
that case, range queries are lexicographical (1, 10, 2, 3, 4...).  Use  
a numeric field type to have range queries work properly.  See Solr's  
example schema.xml for details on these types and range queries.


Erik



On Apr 22, 2010, at 10:00 AM, ZAROGKIKAS,GIORGOS wrote:


Hi there



I 'm a new solr user

With some problems with facets



I have Index a field  like that

9

An I get ranges between

1 an 35

When I Use fq=A00053:[16 TO 30]

I get an results between 1 and 35

It looks like it ignores the second number of each value in my Range



How can I solve that?



Thanks in advance

RE: Analysis / Query problem

[Wagner,Harry]

Thanks Erik.  That helps.

-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 07, 2007 11:36 AM
To: solr-user@lucene.apache.org
Subject: Re: Analysis / Query problem


On Nov 7, 2007, at 10:26 AM, Wagner,Harry wrote:
> I have the following custom field defined for author names.   After  
> indexing the 2 documents below the admin analysis tool looks right  
> for field-name=au and field-value=Schröder, Jürgen   The highlight  
> matching also seems right.  However, if I search for au:Schröder,  
> Jürgen using the admin tool I do not get any hits (see below).   
> This appears to be the case whenever there are 2 non-ascii  
> characters in the author name.  Searching for au:Schröder, Jurgen  
> finds both of these records.  Any idea what is causing this?
>

> 
>
> 
>
> 0
>
> 0
>
> 
>
> on
>
> 0
>
> au:Schröder, Jürgen

One thing to note is that query "au:Schröder, Jürgen" is being  
translated (try &debugQuery=true to see) to:

au:schröder   :jürgen

AND/OR depends on how you have things configured, as well as the  
default field.

You probably want to use the ISOLatin1AccentFilterFactory to have the  
diacritics "flattened" to the ASCII character they look like.

Erik

Re: Analysis / Query problem

[Erik Hatcher]

On Nov 7, 2007, at 10:26 AM, Wagner,Harry wrote:
I have the following custom field defined for author names.   After  
indexing the 2 documents below the admin analysis tool looks right  
for field-name=au and field-value=Schröder, Jürgen   The highlight  
matching also seems right.  However, if I search for au:Schröder,  
Jürgen using the admin tool I do not get any hits (see below).   
This appears to be the case whenever there are 2 non-ascii  
characters in the author name.  Searching for au:Schröder, Jurgen  
finds both of these records.  Any idea what is causing this?









0

0



on

0

au:Schröder, Jürgen


One thing to note is that query "au:Schröder, Jürgen" is being  
translated (try &debugQuery=true to see) to:


au:schröder   :jürgen

AND/OR depends on how you have things configured, as well as the  
default field.


You probably want to use the ISOLatin1AccentFilterFactory to have the  
diacritics "flattened" to the ASCII character they look like.


Erik

Re: Query problem in Solr

[pravesh]

>>We're using Solr to search on a Shop index and a Product index
Do you have 2 separate indexes (using distributed shard search)?? I'm sure
you are actually having only single index.


>> Currently a Shop has a field `shop_keyword` which also contains the
>> keywords of the products assigned to it.

You mean, for a shop, you are first concatenating all keywords of all
products and then saving in shop_keywords field for the shop?? In this case
there is no way u can identify which keyword occurs in which product in ur
index.
You might need to change the index structure, may be, when u post documents,
then post a single document for a single product(with fields like
title,price,shop-id, etc), instead of single document for a single shop.
Hope I make myself clear

--
View this message in context: 
http://lucene.472066.n3.nabble.com/Query-problem-in-Solr-tp3009812p3010072.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Query problem in Solr

[Erick Erickson]

If I read this correctly, one approach is to specify an
increment gap in a multiValued field, then search for phrases
with a slop less than that increment gap. i.e.
incrementGap=100 in your definition, and search for
"apple orange"~99

If this is gibberish, please post some examples and we'll
try something else.

Best
Erick

On Wed, Jun 1, 2011 at 4:21 AM, Kurt Sultana  wrote:
>  Hi all,
>
> We're using Solr to search on a Shop index and a Product index. Currently a
> Shop has a field `shop_keyword` which also contains the keywords of the
> products assigned to it. The shop keywords are separated by a space.
> Consequently, if there is a product which has a keyword "apple" and another
> which has "orange", a search for shops having `Apple AND Orange` would
> return the shop for these products.
>
> However, this is incorrect since we want that a search for shops having
> `Apple AND Orange` returns shop(s) having products with both "apple" and
> "orange" as keywords.
>
> We tried solving this problem, by making shop keywords multi-valued and
> assigning the keywords of every product of the shop as a new value in shop
> keywords. However as was confirmed in another post
> http://markmail.org/thread/xce4qyzs5367yplo#query:+page:1+mid:76eerw5yqev2aanu+state:results,
> Solr does not support "all words must match in the same value of a
> multi-valued field".
>
> (Hope I explained myself well)
>
> How can we go about this? Ideally, we shouldn't change our search
> infrastructure dramatically.
>
> Thanks!
>
> Krt_Malta
>

Re: Query problem in Solr

[Kurt Sultana]

@ Pravesh: It's 2 seperate cores, not 2 indexes. Sorry for that.

@ Erick: Yes, I've seen this suggestion and it seems to be the only possible
solution. I'll look into it.

Thanks for your answers guys!
Kurt

On Wed, Jun 1, 2011 at 4:24 PM, Erick Erickson wrote:

> If I read this correctly, one approach is to specify an
> increment gap in a multiValued field, then search for phrases
> with a slop less than that increment gap. i.e.
> incrementGap=100 in your definition, and search for
> "apple orange"~99
>
> If this is gibberish, please post some examples and we'll
> try something else.
>
> Best
> Erick
>
> On Wed, Jun 1, 2011 at 4:21 AM, Kurt Sultana 
> wrote:
> >  Hi all,
> >
> > We're using Solr to search on a Shop index and a Product index. Currently
> a
> > Shop has a field `shop_keyword` which also contains the keywords of the
> > products assigned to it. The shop keywords are separated by a space.
> > Consequently, if there is a product which has a keyword "apple" and
> another
> > which has "orange", a search for shops having `Apple AND Orange` would
> > return the shop for these products.
> >
> > However, this is incorrect since we want that a search for shops having
> > `Apple AND Orange` returns shop(s) having products with both "apple" and
> > "orange" as keywords.
> >
> > We tried solving this problem, by making shop keywords multi-valued and
> > assigning the keywords of every product of the shop as a new value in
> shop
> > keywords. However as was confirmed in another post
> >
> http://markmail.org/thread/xce4qyzs5367yplo#query:+page:1+mid:76eerw5yqev2aanu+state:results
> ,
> > Solr does not support "all words must match in the same value of a
> > multi-valued field".
> >
> > (Hope I explained myself well)
> >
> > How can we go about this? Ideally, we shouldn't change our search
> > infrastructure dramatically.
> >
> > Thanks!
> >
> > Krt_Malta
> >
>

Query problem related to * symbol

[Aleksey Gogolev]

Hello.

I made this query:
http://localhost:8983/solr/select/?q=suggestion:ipod+nano+80*

and response contains the following doc:
-

 
  04adea06fcfdc939feec63799045076c
 
 
  apple ma045 for ipod 80gb nano
 
 
  2008-10-25T16:50:48.703Z
 

-

Then I made this query (the "g" letter is added):
http://localhost:8983/solr/select/?q=suggestion:ipod+nano+80g*
and I  expect to see the same doc in response, but response was empty.

In first moment I thought that this strange behaviour is caused by
SynonymFilter, but I checked the type of field "suggestion", and it is
quite simple, and the filter chain doesn't contain SynonymFilter:

--













--

Any ideas about reasons of this strange behaviour?

-- 
Aleksey Gogolev
developer, 
dev.co.ua
Aleksey

phrase query problem .. how to?

[rubdabadub]

Hi

Suppose you have a field name with data - Sony CLT2134 handheld
camera. When doing a phrase search like "Sony Camera" or "sony
handheld" -- Solr returns 0 results. Often time our searchers doesn't
know the model number but perform phrase search.. How do I solve this
issue?

Regards

Re: Query problem related to * symbol

[Yonik Seeley]

On Sat, Oct 25, 2008 at 2:00 PM, Aleksey Gogolev <[EMAIL PROTECTED]> wrote:
> I made this query:
> http://localhost:8983/solr/select/?q=suggestion:ipod+nano+80*

Note that in Lucene syntax, this query is equivalent to
suggestion:ipod default_field:nano default_field:80*

For debugging, add debugQuery=true to your request to see what the
parsed query looks like.

-Yonik

Re: phrase query problem .. how to?

[Yonik Seeley]

On 2/4/07, rubdabadub <[EMAIL PROTECTED]> wrote:

Suppose you have a field name with data - Sony CLT2134 handheld
camera. When doing a phrase search like "Sony Camera" or "sony
handheld" -- Solr returns 0 results. Often time our searchers doesn't
know the model number but perform phrase search.. How do I solve this
issue?


If you are controlling the query structure you could
- use a sloppy phrase query... "sony handheld"~10
- use the dismax handler to create a different query structure
- don't use a phrase query at all... change the default operator to
and (q.op=AND)
 to require both terms.

-Yonik