Steven Ou
2012-02-09, 23:42
Erik Hatcher
2012-02-10, 00:08
Steven Ou
2012-02-10, 00:15
Steven Ou
2012-02-10, 00:20
Steven Ou
2012-02-10, 00:24
Erik Hatcher
2012-02-10, 00:39
Steven Ou
2012-02-10, 00:48
Steven Ou
2012-02-10, 00:53
Steven Ou
2012-02-10, 00:57
Erik Hatcher
2012-02-10, 01:01
Steven Ou
2012-02-10, 01:11
Erik Hatcher
2012-02-10, 01:14
Steven Ou
2012-02-10, 19:08
-
Empty results with OR filter querySteven Ou 2012-02-09, 23:42
Hey guys, I'm stumped - hope someone can help!
Basically, I'm running a filter query that filters by category (e.g.
fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
results whatsoever even though each individual query *does* produce results.
So, for example, fq=category_ids_im:*637* produces
results. fq=category_ids_im:*639* produces results.
fq=category_ids_im:*634* produces
results. Even fq=category_ids_im:(*637* OR *639*) produces results, as well
as fq=category_ids_im:(*639* OR *634*).
BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
produces NO RESULTS!
Any ideas what might be wrong? Really appreciate any help!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
Basically, I'm running a filter query that filters by category (e.g.
fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
results whatsoever even though each individual query *does* produce results.
So, for example, fq=category_ids_im:*637* produces
results. fq=category_ids_im:*639* produces results.
fq=category_ids_im:*634* produces
results. Even fq=category_ids_im:(*637* OR *639*) produces results, as well
as fq=category_ids_im:(*639* OR *634*).
BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
produces NO RESULTS!
Any ideas what might be wrong? Really appreciate any help!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
+
Steven Ou 2012-02-09, 23:42
-
Re: Empty results with OR filter queryErik Hatcher 2012-02-10, 00:08
What type of field is category_ids_im?
And I'm assuming that the *'s below are for emphasis and not really in your query?
Try your query in the q parameter and turn on debug (&debugQuery=true) and see how your query is parsing. That'll likely tell all.
Erik
On Feb 9, 2012, at 18:42 , Steven Ou wrote:
> Hey guys, I'm stumped - hope someone can help!
>
> Basically, I'm running a filter query that filters by category (e.g.
> fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
> results whatsoever even though each individual query *does* produce results.
>
> So, for example, fq=category_ids_im:*637* produces
> results. fq=category_ids_im:*639* produces results.
> fq=category_ids_im:*634* produces
> results. Even fq=category_ids_im:(*637* OR *639*) produces results, as well
> as fq=category_ids_im:(*639* OR *634*).
>
> BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
> produces NO RESULTS!
>
> Any ideas what might be wrong? Really appreciate any help!
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
And I'm assuming that the *'s below are for emphasis and not really in your query?
Try your query in the q parameter and turn on debug (&debugQuery=true) and see how your query is parsing. That'll likely tell all.
Erik
On Feb 9, 2012, at 18:42 , Steven Ou wrote:
> Hey guys, I'm stumped - hope someone can help!
>
> Basically, I'm running a filter query that filters by category (e.g.
> fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
> results whatsoever even though each individual query *does* produce results.
>
> So, for example, fq=category_ids_im:*637* produces
> results. fq=category_ids_im:*639* produces results.
> fq=category_ids_im:*634* produces
> results. Even fq=category_ids_im:(*637* OR *639*) produces results, as well
> as fq=category_ids_im:(*639* OR *634*).
>
> BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
> produces NO RESULTS!
>
> Any ideas what might be wrong? Really appreciate any help!
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
+
Erik Hatcher 2012-02-10, 00:08
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:15
Heh, yeah, I bolded the numbers for emphasis. The field type follows.
*Dynamically Created From Pattern:
**_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
*Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
*Schema: *Indexed, Multivalued, Omit Norms
*Index: *(unstored field)
*Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
*Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
*Docs: *33730
*Distinct: *528
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> What type of field is category_ids_im?
>
> And I'm assuming that the *'s below are for emphasis and not really in
> your query?
>
> Try your query in the q parameter and turn on debug (&debugQuery=true) and
> see how your query is parsing. That'll likely tell all.
>
> Erik
>
> On Feb 9, 2012, at 18:42 , Steven Ou wrote:
>
> > Hey guys, I'm stumped - hope someone can help!
> >
> > Basically, I'm running a filter query that filters by category (e.g.
> > fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
> > results whatsoever even though each individual query *does* produce
> results.
> >
> > So, for example, fq=category_ids_im:*637* produces
> > results. fq=category_ids_im:*639* produces results.
> > fq=category_ids_im:*634* produces
> > results. Even fq=category_ids_im:(*637* OR *639*) produces results, as
> well
> > as fq=category_ids_im:(*639* OR *634*).
> >
> > BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
> > produces NO RESULTS!
> >
> > Any ideas what might be wrong? Really appreciate any help!
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
>
>
*Dynamically Created From Pattern:
**_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
*Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
*Schema: *Indexed, Multivalued, Omit Norms
*Index: *(unstored field)
*Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
*Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
*Docs: *33730
*Distinct: *528
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> What type of field is category_ids_im?
>
> And I'm assuming that the *'s below are for emphasis and not really in
> your query?
>
> Try your query in the q parameter and turn on debug (&debugQuery=true) and
> see how your query is parsing. That'll likely tell all.
>
> Erik
>
> On Feb 9, 2012, at 18:42 , Steven Ou wrote:
>
> > Hey guys, I'm stumped - hope someone can help!
> >
> > Basically, I'm running a filter query that filters by category (e.g.
> > fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
> > results whatsoever even though each individual query *does* produce
> results.
> >
> > So, for example, fq=category_ids_im:*637* produces
> > results. fq=category_ids_im:*639* produces results.
> > fq=category_ids_im:*634* produces
> > results. Even fq=category_ids_im:(*637* OR *639*) produces results, as
> well
> > as fq=category_ids_im:(*639* OR *634*).
> >
> > BUT as soon as I do fq=category_ids_im:(*637* OR *639* OR *634*), it
> > produces NO RESULTS!
> >
> > Any ideas what might be wrong? Really appreciate any help!
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
>
>
+
Steven Ou 2012-02-10, 00:15
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:20
I don't really know how to analyze the debug output... Here it is for the
full query I'm running, which includes other filter queries.
<lst name="debug">
<str name="rawquerystring">*:*</str>
<str name="querystring">*:*</str>
<str name="parsedquery">MatchAllDocsQuery(*:*)</str>
<str name="parsedquery_toString">*:*</str>
<lst name="explain"/>
<str name="QParser">LuceneQParser</str>
<arr name="filter_queries">
<str>type:Event</str>
<str>displayable_b:true</str>
<str>category_ids_im:(637 OR 639 OR 634)</str>
<str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
<str>{!geofilt}</str>
</arr>
<arr name="parsed_filter_queries">
<str>type:Event</str>
<str>displayable_b:true</str>
<str>
category_ids_im:637 category_ids_im:639 category_ids_im:634
</str>
<str>end_datetime_dt:[1328833072000 TO *]</str>
<str>
SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
</str>
</arr>
<lst name="timing">
<double name="time">1.0</double>
<lst name="prepare">
<double name="time">1.0</double>
<lst name="org.apache.solr.handler.component.QueryComponent">
<double name="time">1.0</double>
</lst>
<lst name="org.apache.solr.handler.component.FacetComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.HighlightComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.StatsComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.DebugComponent">
<double name="time">0.0</double>
</lst>
</lst>
<lst name="process">
<double name="time">0.0</double>
<lst name="org.apache.solr.handler.component.QueryComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.FacetComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.HighlightComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.StatsComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.DebugComponent">
<double name="time">0.0</double>
</lst>
</lst>
</lst>
</lst>
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>
> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
>
> *Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
>
> *Schema: *Indexed, Multivalued, Omit Norms
>
> *Index: *(unstored field)
>
> *Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>
> *Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>
> *Docs: *33730
>
> *Distinct: *528
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
>
> On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>
>> What type of field is category_ids_im?
>>
>> And I'm assuming that the *'s below are for emphasis and not really in
>> your query?
>>
>> Try your query in the q parameter and turn on debug (&debugQuery=true)
>> and see how your query is parsing. That'll likely tell all.
>>
>> Erik
>>
>> On Feb 9, 2012, at 18:42 , Steven Ou wrote:
>>
>> > Hey guys, I'm stumped - hope someone can help!
>> >
>> > Basically, I'm running a filter query that filters by category (e.g.
>> > fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
full query I'm running, which includes other filter queries.
<lst name="debug">
<str name="rawquerystring">*:*</str>
<str name="querystring">*:*</str>
<str name="parsedquery">MatchAllDocsQuery(*:*)</str>
<str name="parsedquery_toString">*:*</str>
<lst name="explain"/>
<str name="QParser">LuceneQParser</str>
<arr name="filter_queries">
<str>type:Event</str>
<str>displayable_b:true</str>
<str>category_ids_im:(637 OR 639 OR 634)</str>
<str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
<str>{!geofilt}</str>
</arr>
<arr name="parsed_filter_queries">
<str>type:Event</str>
<str>displayable_b:true</str>
<str>
category_ids_im:637 category_ids_im:639 category_ids_im:634
</str>
<str>end_datetime_dt:[1328833072000 TO *]</str>
<str>
SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
</str>
</arr>
<lst name="timing">
<double name="time">1.0</double>
<lst name="prepare">
<double name="time">1.0</double>
<lst name="org.apache.solr.handler.component.QueryComponent">
<double name="time">1.0</double>
</lst>
<lst name="org.apache.solr.handler.component.FacetComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.HighlightComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.StatsComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.DebugComponent">
<double name="time">0.0</double>
</lst>
</lst>
<lst name="process">
<double name="time">0.0</double>
<lst name="org.apache.solr.handler.component.QueryComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.FacetComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.HighlightComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.StatsComponent">
<double name="time">0.0</double>
</lst>
<lst name="org.apache.solr.handler.component.DebugComponent">
<double name="time">0.0</double>
</lst>
</lst>
</lst>
</lst>
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>
> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
>
> *Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
>
> *Schema: *Indexed, Multivalued, Omit Norms
>
> *Index: *(unstored field)
>
> *Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>
> *Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>
> *Docs: *33730
>
> *Distinct: *528
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
>
> On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>
>> What type of field is category_ids_im?
>>
>> And I'm assuming that the *'s below are for emphasis and not really in
>> your query?
>>
>> Try your query in the q parameter and turn on debug (&debugQuery=true)
>> and see how your query is parsing. That'll likely tell all.
>>
>> Erik
>>
>> On Feb 9, 2012, at 18:42 , Steven Ou wrote:
>>
>> > Hey guys, I'm stumped - hope someone can help!
>> >
>> > Basically, I'm running a filter query that filters by category (e.g.
>> > fq=category_ids_im:(637 OR 639 OR 634)). However, it often produces no
+
Steven Ou 2012-02-10, 00:20
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:24
By turning fq=category_ids_im:(637+OR+639+OR+634) to
q=category_ids_im:(637+OR+639+OR+634)
it appears to produce the correct results. But... that doesn't seem to make
sense to me? Shouldn't it work just fine as a filter query?
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> I don't really know how to analyze the debug output... Here it is for the
> full query I'm running, which includes other filter queries.
>
> <lst name="debug">
> <str name="rawquerystring">*:*</str>
> <str name="querystring">*:*</str>
> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> <str name="parsedquery_toString">*:*</str>
> <lst name="explain"/>
> <str name="QParser">LuceneQParser</str>
> <arr name="filter_queries">
> <str>type:Event</str>
> <str>displayable_b:true</str>
> <str>category_ids_im:(637 OR 639 OR 634)</str>
> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> <str>{!geofilt}</str>
> </arr>
> <arr name="parsed_filter_queries">
> <str>type:Event</str>
> <str>displayable_b:true</str>
> <str>
> category_ids_im:637 category_ids_im:639 category_ids_im:634
> </str>
> <str>end_datetime_dt:[1328833072000 TO *]</str>
> <str>
>
> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
> </str>
> </arr>
> <lst name="timing">
> <double name="time">1.0</double>
> <lst name="prepare">
> <double name="time">1.0</double>
> <lst name="org.apache.solr.handler.component.QueryComponent">
> <double name="time">1.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.FacetComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.HighlightComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.StatsComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.DebugComponent">
> <double name="time">0.0</double>
> </lst>
> </lst>
> <lst name="process">
> <double name="time">0.0</double>
> <lst name="org.apache.solr.handler.component.QueryComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.FacetComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.HighlightComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.StatsComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.DebugComponent">
> <double name="time">0.0</double>
> </lst>
> </lst>
> </lst>
> </lst>
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>>
>> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
>>
>> *Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
>>
>> *Schema: *Indexed, Multivalued, Omit Norms
>>
>> *Index: *(unstored field)
>>
>> *Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>>
>> *Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>>
>> *Docs: *33730
>>
>> *Distinct: *528
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
q=category_ids_im:(637+OR+639+OR+634)
it appears to produce the correct results. But... that doesn't seem to make
sense to me? Shouldn't it work just fine as a filter query?
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> I don't really know how to analyze the debug output... Here it is for the
> full query I'm running, which includes other filter queries.
>
> <lst name="debug">
> <str name="rawquerystring">*:*</str>
> <str name="querystring">*:*</str>
> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> <str name="parsedquery_toString">*:*</str>
> <lst name="explain"/>
> <str name="QParser">LuceneQParser</str>
> <arr name="filter_queries">
> <str>type:Event</str>
> <str>displayable_b:true</str>
> <str>category_ids_im:(637 OR 639 OR 634)</str>
> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> <str>{!geofilt}</str>
> </arr>
> <arr name="parsed_filter_queries">
> <str>type:Event</str>
> <str>displayable_b:true</str>
> <str>
> category_ids_im:637 category_ids_im:639 category_ids_im:634
> </str>
> <str>end_datetime_dt:[1328833072000 TO *]</str>
> <str>
>
> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
> </str>
> </arr>
> <lst name="timing">
> <double name="time">1.0</double>
> <lst name="prepare">
> <double name="time">1.0</double>
> <lst name="org.apache.solr.handler.component.QueryComponent">
> <double name="time">1.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.FacetComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.HighlightComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.StatsComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.DebugComponent">
> <double name="time">0.0</double>
> </lst>
> </lst>
> <lst name="process">
> <double name="time">0.0</double>
> <lst name="org.apache.solr.handler.component.QueryComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.FacetComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.HighlightComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.StatsComponent">
> <double name="time">0.0</double>
> </lst>
> <lst name="org.apache.solr.handler.component.DebugComponent">
> <double name="time">0.0</double>
> </lst>
> </lst>
> </lst>
> </lst>
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>>
>> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
>>
>> *Field Type: *SINT <http://192.168.1.30:8080/solr/admin/schema.jsp#>
>>
>> *Schema: *Indexed, Multivalued, Omit Norms
>>
>> *Index: *(unstored field)
>>
>> *Index Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>>
>> *Query Analyzer: *org.apache.solr.schema.FieldType$DefaultAnalyzer
>>
>> *Docs: *33730
>>
>> *Distinct: *528
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:08 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
+
Steven Ou 2012-02-10, 00:24
-
Re: Empty results with OR filter queryErik Hatcher 2012-02-10, 00:39
Yes, certainly should work fine as a filter query... I was merely trying to eliminate variables from the equation. You've got several filters and a q=*:* going on below, so it's obviously harder to pinpoint what could be going wrong. I suggest continuing to eliminate variables here, as more than likely some other filter is causing the documents you think should appear to be filtered out.
Erik
On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> q=category_ids_im:(637+OR+639+OR+634)
> it appears to produce the correct results. But... that doesn't seem to make
> sense to me? Shouldn't it work just fine as a filter query?
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> I don't really know how to analyze the debug output... Here it is for the
>> full query I'm running, which includes other filter queries.
>>
>> <lst name="debug">
>> <str name="rawquerystring">*:*</str>
>> <str name="querystring">*:*</str>
>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>> <str name="parsedquery_toString">*:*</str>
>> <lst name="explain"/>
>> <str name="QParser">LuceneQParser</str>
>> <arr name="filter_queries">
>> <str>type:Event</str>
>> <str>displayable_b:true</str>
>> <str>category_ids_im:(637 OR 639 OR 634)</str>
>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>> <str>{!geofilt}</str>
>> </arr>
>> <arr name="parsed_filter_queries">
>> <str>type:Event</str>
>> <str>displayable_b:true</str>
>> <str>
>> category_ids_im:637 category_ids_im:639 category_ids_im:634
>> </str>
>> <str>end_datetime_dt:[1328833072000 TO *]</str>
>> <str>
>>
>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>> </str>
>> </arr>
>> <lst name="timing">
>> <double name="time">1.0</double>
>> <lst name="prepare">
>> <double name="time">1.0</double>
>> <lst name="org.apache.solr.handler.component.QueryComponent">
>> <double name="time">1.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.FacetComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.StatsComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.DebugComponent">
>> <double name="time">0.0</double>
>> </lst>
>> </lst>
>> <lst name="process">
>> <double name="time">0.0</double>
>> <lst name="org.apache.solr.handler.component.QueryComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.FacetComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.StatsComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.DebugComponent">
>> <double name="time">0.0</double>
>> </lst>
>> </lst>
>> </lst>
>> </lst>
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>> On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>
>>> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>>>
>>> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
Erik
On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> q=category_ids_im:(637+OR+639+OR+634)
> it appears to produce the correct results. But... that doesn't seem to make
> sense to me? Shouldn't it work just fine as a filter query?
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> I don't really know how to analyze the debug output... Here it is for the
>> full query I'm running, which includes other filter queries.
>>
>> <lst name="debug">
>> <str name="rawquerystring">*:*</str>
>> <str name="querystring">*:*</str>
>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>> <str name="parsedquery_toString">*:*</str>
>> <lst name="explain"/>
>> <str name="QParser">LuceneQParser</str>
>> <arr name="filter_queries">
>> <str>type:Event</str>
>> <str>displayable_b:true</str>
>> <str>category_ids_im:(637 OR 639 OR 634)</str>
>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>> <str>{!geofilt}</str>
>> </arr>
>> <arr name="parsed_filter_queries">
>> <str>type:Event</str>
>> <str>displayable_b:true</str>
>> <str>
>> category_ids_im:637 category_ids_im:639 category_ids_im:634
>> </str>
>> <str>end_datetime_dt:[1328833072000 TO *]</str>
>> <str>
>>
>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>> </str>
>> </arr>
>> <lst name="timing">
>> <double name="time">1.0</double>
>> <lst name="prepare">
>> <double name="time">1.0</double>
>> <lst name="org.apache.solr.handler.component.QueryComponent">
>> <double name="time">1.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.FacetComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.StatsComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.DebugComponent">
>> <double name="time">0.0</double>
>> </lst>
>> </lst>
>> <lst name="process">
>> <double name="time">0.0</double>
>> <lst name="org.apache.solr.handler.component.QueryComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.FacetComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.StatsComponent">
>> <double name="time">0.0</double>
>> </lst>
>> <lst name="org.apache.solr.handler.component.DebugComponent">
>> <double name="time">0.0</double>
>> </lst>
>> </lst>
>> </lst>
>> </lst>
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>> On Thu, Feb 9, 2012 at 4:15 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>
>>> Heh, yeah, I bolded the numbers for emphasis. The field type follows.
>>>
>>> *Dynamically Created From Pattern: **_IM<http://192.168.1.30:8080/solr/admin/schema.jsp#>
+
Erik Hatcher 2012-02-10, 00:39
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:48
Well, keeping all other filter queries the same, changing fqcategory_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
causes results to not show up.
In fact, I took out *all* other filter queries. And while I wasn't able to
reproduce it exactly, nonetheless when I added the third category id the
number of results *went down*. Which is consistently inconsistent, per se.
Adding an OR cannot, logically, reduce the number of results!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Yes, certainly should work fine as a filter query... I was merely trying
> to eliminate variables from the equation. You've got several filters and a
> q=*:* going on below, so it's obviously harder to pinpoint what could be
> going wrong. I suggest continuing to eliminate variables here, as more
> than likely some other filter is causing the documents you think should
> appear to be filtered out.
>
> Erik
>
>
>
> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>
> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
> > q=category_ids_im:(637+OR+639+OR+634)
> > it appears to produce the correct results. But... that doesn't seem to
> make
> > sense to me? Shouldn't it work just fine as a filter query?
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >
> >> I don't really know how to analyze the debug output... Here it is for
> the
> >> full query I'm running, which includes other filter queries.
> >>
> >> <lst name="debug">
> >> <str name="rawquerystring">*:*</str>
> >> <str name="querystring">*:*</str>
> >> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> >> <str name="parsedquery_toString">*:*</str>
> >> <lst name="explain"/>
> >> <str name="QParser">LuceneQParser</str>
> >> <arr name="filter_queries">
> >> <str>type:Event</str>
> >> <str>displayable_b:true</str>
> >> <str>category_ids_im:(637 OR 639 OR 634)</str>
> >> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> >> <str>{!geofilt}</str>
> >> </arr>
> >> <arr name="parsed_filter_queries">
> >> <str>type:Event</str>
> >> <str>displayable_b:true</str>
> >> <str>
> >> category_ids_im:637 category_ids_im:639 category_ids_im:634
> >> </str>
> >> <str>end_datetime_dt:[1328833072000 TO *]</str>
> >> <str>
> >>
> >>
> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
> >> </str>
> >> </arr>
> >> <lst name="timing">
> >> <double name="time">1.0</double>
> >> <lst name="prepare">
> >> <double name="time">1.0</double>
> >> <lst name="org.apache.solr.handler.component.QueryComponent">
> >> <double name="time">1.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.FacetComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.HighlightComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.StatsComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.DebugComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> </lst>
> >> <lst name="process">
> >> <double name="time">0.0</double>
> >> <lst name="org.apache.solr.handler.component.QueryComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.FacetComponent">
> >> <double name="time">0.0</double>
causes results to not show up.
In fact, I took out *all* other filter queries. And while I wasn't able to
reproduce it exactly, nonetheless when I added the third category id the
number of results *went down*. Which is consistently inconsistent, per se.
Adding an OR cannot, logically, reduce the number of results!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Yes, certainly should work fine as a filter query... I was merely trying
> to eliminate variables from the equation. You've got several filters and a
> q=*:* going on below, so it's obviously harder to pinpoint what could be
> going wrong. I suggest continuing to eliminate variables here, as more
> than likely some other filter is causing the documents you think should
> appear to be filtered out.
>
> Erik
>
>
>
> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>
> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
> > q=category_ids_im:(637+OR+639+OR+634)
> > it appears to produce the correct results. But... that doesn't seem to
> make
> > sense to me? Shouldn't it work just fine as a filter query?
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >
> >> I don't really know how to analyze the debug output... Here it is for
> the
> >> full query I'm running, which includes other filter queries.
> >>
> >> <lst name="debug">
> >> <str name="rawquerystring">*:*</str>
> >> <str name="querystring">*:*</str>
> >> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> >> <str name="parsedquery_toString">*:*</str>
> >> <lst name="explain"/>
> >> <str name="QParser">LuceneQParser</str>
> >> <arr name="filter_queries">
> >> <str>type:Event</str>
> >> <str>displayable_b:true</str>
> >> <str>category_ids_im:(637 OR 639 OR 634)</str>
> >> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> >> <str>{!geofilt}</str>
> >> </arr>
> >> <arr name="parsed_filter_queries">
> >> <str>type:Event</str>
> >> <str>displayable_b:true</str>
> >> <str>
> >> category_ids_im:637 category_ids_im:639 category_ids_im:634
> >> </str>
> >> <str>end_datetime_dt:[1328833072000 TO *]</str>
> >> <str>
> >>
> >>
> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
> >> </str>
> >> </arr>
> >> <lst name="timing">
> >> <double name="time">1.0</double>
> >> <lst name="prepare">
> >> <double name="time">1.0</double>
> >> <lst name="org.apache.solr.handler.component.QueryComponent">
> >> <double name="time">1.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.FacetComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.HighlightComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.StatsComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.DebugComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> </lst>
> >> <lst name="process">
> >> <double name="time">0.0</double>
> >> <lst name="org.apache.solr.handler.component.QueryComponent">
> >> <double name="time">0.0</double>
> >> </lst>
> >> <lst name="org.apache.solr.handler.component.FacetComponent">
> >> <double name="time">0.0</double>
+
Steven Ou 2012-02-10, 00:48
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:53
Actually, I take that back. Using q instead of fq still produces the same
problem. Somehow it's *less* inconsistent so at first glance it looked like
it fixed it. However, it does *not* fix it :(
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Well, keeping all other filter queries the same, changing fq> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> causes results to not show up.
>
> In fact, I took out *all* other filter queries. And while I wasn't able
> to reproduce it exactly, nonetheless when I added the third category id the
> number of results *went down*. Which is consistently inconsistent, per
> se. Adding an OR cannot, logically, reduce the number of results!
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
>
> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>
>> Yes, certainly should work fine as a filter query... I was merely trying
>> to eliminate variables from the equation. You've got several filters and a
>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>> going wrong. I suggest continuing to eliminate variables here, as more
>> than likely some other filter is causing the documents you think should
>> appear to be filtered out.
>>
>> Erik
>>
>>
>>
>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>
>> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
>> > q=category_ids_im:(637+OR+639+OR+634)
>> > it appears to produce the correct results. But... that doesn't seem to
>> make
>> > sense to me? Shouldn't it work just fine as a filter query?
>> > --
>> > Steven Ou | 歐偉凡
>> >
>> > *ravn.com* | Chief Technology Officer
>> > [EMAIL PROTECTED] | +1 909-569-9880
>> >
>> >
>> > On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>> >
>> >> I don't really know how to analyze the debug output... Here it is for
>> the
>> >> full query I'm running, which includes other filter queries.
>> >>
>> >> <lst name="debug">
>> >> <str name="rawquerystring">*:*</str>
>> >> <str name="querystring">*:*</str>
>> >> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>> >> <str name="parsedquery_toString">*:*</str>
>> >> <lst name="explain"/>
>> >> <str name="QParser">LuceneQParser</str>
>> >> <arr name="filter_queries">
>> >> <str>type:Event</str>
>> >> <str>displayable_b:true</str>
>> >> <str>category_ids_im:(637 OR 639 OR 634)</str>
>> >> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>> >> <str>{!geofilt}</str>
>> >> </arr>
>> >> <arr name="parsed_filter_queries">
>> >> <str>type:Event</str>
>> >> <str>displayable_b:true</str>
>> >> <str>
>> >> category_ids_im:637 category_ids_im:639 category_ids_im:634
>> >> </str>
>> >> <str>end_datetime_dt:[1328833072000 TO *]</str>
>> >> <str>
>> >>
>> >>
>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>> >> </str>
>> >> </arr>
>> >> <lst name="timing">
>> >> <double name="time">1.0</double>
>> >> <lst name="prepare">
>> >> <double name="time">1.0</double>
>> >> <lst name="org.apache.solr.handler.component.QueryComponent">
>> >> <double name="time">1.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.FacetComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.StatsComponent">
problem. Somehow it's *less* inconsistent so at first glance it looked like
it fixed it. However, it does *not* fix it :(
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Well, keeping all other filter queries the same, changing fq> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> causes results to not show up.
>
> In fact, I took out *all* other filter queries. And while I wasn't able
> to reproduce it exactly, nonetheless when I added the third category id the
> number of results *went down*. Which is consistently inconsistent, per
> se. Adding an OR cannot, logically, reduce the number of results!
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
>
> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>
>> Yes, certainly should work fine as a filter query... I was merely trying
>> to eliminate variables from the equation. You've got several filters and a
>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>> going wrong. I suggest continuing to eliminate variables here, as more
>> than likely some other filter is causing the documents you think should
>> appear to be filtered out.
>>
>> Erik
>>
>>
>>
>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>
>> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
>> > q=category_ids_im:(637+OR+639+OR+634)
>> > it appears to produce the correct results. But... that doesn't seem to
>> make
>> > sense to me? Shouldn't it work just fine as a filter query?
>> > --
>> > Steven Ou | 歐偉凡
>> >
>> > *ravn.com* | Chief Technology Officer
>> > [EMAIL PROTECTED] | +1 909-569-9880
>> >
>> >
>> > On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>> >
>> >> I don't really know how to analyze the debug output... Here it is for
>> the
>> >> full query I'm running, which includes other filter queries.
>> >>
>> >> <lst name="debug">
>> >> <str name="rawquerystring">*:*</str>
>> >> <str name="querystring">*:*</str>
>> >> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>> >> <str name="parsedquery_toString">*:*</str>
>> >> <lst name="explain"/>
>> >> <str name="QParser">LuceneQParser</str>
>> >> <arr name="filter_queries">
>> >> <str>type:Event</str>
>> >> <str>displayable_b:true</str>
>> >> <str>category_ids_im:(637 OR 639 OR 634)</str>
>> >> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>> >> <str>{!geofilt}</str>
>> >> </arr>
>> >> <arr name="parsed_filter_queries">
>> >> <str>type:Event</str>
>> >> <str>displayable_b:true</str>
>> >> <str>
>> >> category_ids_im:637 category_ids_im:639 category_ids_im:634
>> >> </str>
>> >> <str>end_datetime_dt:[1328833072000 TO *]</str>
>> >> <str>
>> >>
>> >>
>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>> >> </str>
>> >> </arr>
>> >> <lst name="timing">
>> >> <double name="time">1.0</double>
>> >> <lst name="prepare">
>> >> <double name="time">1.0</double>
>> >> <lst name="org.apache.solr.handler.component.QueryComponent">
>> >> <double name="time">1.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.FacetComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.MoreLikeThisComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.HighlightComponent">
>> >> <double name="time">0.0</double>
>> >> </lst>
>> >> <lst name="org.apache.solr.handler.component.StatsComponent">
+
Steven Ou 2012-02-10, 00:53
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 00:57
I'm really sorry to be spamming everyone. I know I've sent out a ton of
emails, but I ran it without *any* other filters (just
solr/select?q=category_ids_im:(637+OR+639+OR+634)&debugQuery=true) and
here's the debug. This produces 1 result only. Removing category 634
produces 11 results. Can anyone help? I noticed the parsedquery_toString
has weird symbols in it:
<lst name="debug">
<str name="rawquerystring">category_ids_im:(637 OR 639 OR 634)</str>
<str name="querystring">category_ids_im:(637 OR 639 OR 634)</str>
<str name="parsedquery">
category_ids_im:637 category_ids_im:639 category_ids_im:634
</str>
<str name="parsedquery_toString">
category_ids_im:€#0;ɽ category_ids_im:€#0;ɿ category_ids_im:€#0;ɺ
</str>
<lst name="explain">
<str name="Event 4317">
11.743038 = (MATCH) sum of: 4.007905 = (MATCH) weight(category_ids_im:€#0;ɽ
in 4268), product of: 0.5842093 = queryWeight(category_ids_im:€#0;ɽ),
product of: 6.860392 = idf(docFreq=187, maxDocs=65962) 0.08515684 queryNorm 6.860392 = (MATCH) fieldWeight(category_ids_im:€#0;ɽ in 4268),
product of: 1.0 = tf(termFreq(category_ids_im:€#0;ɽ)=1) 6.860392 idf(docFreq=187, maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im,
doc=4268) 3.959362 = (MATCH) weight(category_ids_im:€#0;ɿ in 4268), product
of: 0.58066064 = queryWeight(category_ids_im:€#0;ɿ), product of: 6.8187194
= idf(docFreq=195, maxDocs=65962) 0.08515684 = queryNorm 6.8187194 (MATCH) fieldWeight(category_ids_im:€#0;ɿ in 4268), product of: 1.0 tf(termFreq(category_ids_im:€#0;ɿ)=1) 6.8187194 = idf(docFreq=195,
maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im, doc=4268) 3.7757707 (MATCH) weight(category_ids_im:€#0;ɺ in 4268), product of: 0.56703854 queryWeight(category_ids_im:€#0;ɺ), product of: 6.658755 = idf(docFreq=229,
maxDocs=65962) 0.08515684 = queryNorm 6.658755 = (MATCH)
fieldWeight(category_ids_im:€#0;ɺ in 4268), product of: 1.0 tf(termFreq(category_ids_im:€#0;ɺ)=1) 6.658755 = idf(docFreq=229,
maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im, doc=4268)
</str>
</lst>
<str name="QParser">LuceneQParser</str>
<lst name="timing">...</lst>
</lst>
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:53 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Actually, I take that back. Using q instead of fq still produces the same
> problem. Somehow it's *less* inconsistent so at first glance it looked
> like it fixed it. However, it does *not* fix it :(
>
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Well, keeping all other filter queries the same, changing fq>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
>> causes results to not show up.
>>
>> In fact, I took out *all* other filter queries. And while I wasn't able
>> to reproduce it exactly, nonetheless when I added the third category id the
>> number of results *went down*. Which is consistently inconsistent, per
>> se. Adding an OR cannot, logically, reduce the number of results!
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>>
>>> Yes, certainly should work fine as a filter query... I was merely trying
>>> to eliminate variables from the equation. You've got several filters and a
>>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>>> going wrong. I suggest continuing to eliminate variables here, as more
>>> than likely some other filter is causing the documents you think should
>>> appear to be filtered out.
>>>
>>> Erik
>>>
>>>
>>>
>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>>
>>> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
>>> > q=category_ids_im:(637+OR+639+OR+634)
>>> > it appears to produce the correct results. But... that doesn't seem to
emails, but I ran it without *any* other filters (just
solr/select?q=category_ids_im:(637+OR+639+OR+634)&debugQuery=true) and
here's the debug. This produces 1 result only. Removing category 634
produces 11 results. Can anyone help? I noticed the parsedquery_toString
has weird symbols in it:
<lst name="debug">
<str name="rawquerystring">category_ids_im:(637 OR 639 OR 634)</str>
<str name="querystring">category_ids_im:(637 OR 639 OR 634)</str>
<str name="parsedquery">
category_ids_im:637 category_ids_im:639 category_ids_im:634
</str>
<str name="parsedquery_toString">
category_ids_im:€#0;ɽ category_ids_im:€#0;ɿ category_ids_im:€#0;ɺ
</str>
<lst name="explain">
<str name="Event 4317">
11.743038 = (MATCH) sum of: 4.007905 = (MATCH) weight(category_ids_im:€#0;ɽ
in 4268), product of: 0.5842093 = queryWeight(category_ids_im:€#0;ɽ),
product of: 6.860392 = idf(docFreq=187, maxDocs=65962) 0.08515684 queryNorm 6.860392 = (MATCH) fieldWeight(category_ids_im:€#0;ɽ in 4268),
product of: 1.0 = tf(termFreq(category_ids_im:€#0;ɽ)=1) 6.860392 idf(docFreq=187, maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im,
doc=4268) 3.959362 = (MATCH) weight(category_ids_im:€#0;ɿ in 4268), product
of: 0.58066064 = queryWeight(category_ids_im:€#0;ɿ), product of: 6.8187194
= idf(docFreq=195, maxDocs=65962) 0.08515684 = queryNorm 6.8187194 (MATCH) fieldWeight(category_ids_im:€#0;ɿ in 4268), product of: 1.0 tf(termFreq(category_ids_im:€#0;ɿ)=1) 6.8187194 = idf(docFreq=195,
maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im, doc=4268) 3.7757707 (MATCH) weight(category_ids_im:€#0;ɺ in 4268), product of: 0.56703854 queryWeight(category_ids_im:€#0;ɺ), product of: 6.658755 = idf(docFreq=229,
maxDocs=65962) 0.08515684 = queryNorm 6.658755 = (MATCH)
fieldWeight(category_ids_im:€#0;ɺ in 4268), product of: 1.0 tf(termFreq(category_ids_im:€#0;ɺ)=1) 6.658755 = idf(docFreq=229,
maxDocs=65962) 1.0 = fieldNorm(field=category_ids_im, doc=4268)
</str>
</lst>
<str name="QParser">LuceneQParser</str>
<lst name="timing">...</lst>
</lst>
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 4:53 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> Actually, I take that back. Using q instead of fq still produces the same
> problem. Somehow it's *less* inconsistent so at first glance it looked
> like it fixed it. However, it does *not* fix it :(
>
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Well, keeping all other filter queries the same, changing fq>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
>> causes results to not show up.
>>
>> In fact, I took out *all* other filter queries. And while I wasn't able
>> to reproduce it exactly, nonetheless when I added the third category id the
>> number of results *went down*. Which is consistently inconsistent, per
>> se. Adding an OR cannot, logically, reduce the number of results!
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>>
>>> Yes, certainly should work fine as a filter query... I was merely trying
>>> to eliminate variables from the equation. You've got several filters and a
>>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>>> going wrong. I suggest continuing to eliminate variables here, as more
>>> than likely some other filter is causing the documents you think should
>>> appear to be filtered out.
>>>
>>> Erik
>>>
>>>
>>>
>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>>
>>> > By turning fq=category_ids_im:(637+OR+639+OR+634) to
>>> > q=category_ids_im:(637+OR+639+OR+634)
>>> > it appears to produce the correct results. But... that doesn't seem to
+
Steven Ou 2012-02-10, 00:57
-
Re: Empty results with OR filter queryErik Hatcher 2012-02-10, 01:01
Extremely odd.
Hmmm... other things to try:
* query on an explicit category, rather than in a boolean expression
* try a different field type than sint (say just int, or string)
* shouldn't matter (since you're using "OR" explicitly) but double check the default operator in schema.xml
* reindex (was the field type ever changed mid-stream?)
Definitely something fishy here. Nothing obvious pops out yet.
Erik
On Feb 9, 2012, at 19:53 , Steven Ou wrote:
> Actually, I take that back. Using q instead of fq still produces the same
> problem. Somehow it's *less* inconsistent so at first glance it looked like
> it fixed it. However, it does *not* fix it :(
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Well, keeping all other filter queries the same, changing fq>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
>> causes results to not show up.
>>
>> In fact, I took out *all* other filter queries. And while I wasn't able
>> to reproduce it exactly, nonetheless when I added the third category id the
>> number of results *went down*. Which is consistently inconsistent, per
>> se. Adding an OR cannot, logically, reduce the number of results!
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>>
>>> Yes, certainly should work fine as a filter query... I was merely trying
>>> to eliminate variables from the equation. You've got several filters and a
>>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>>> going wrong. I suggest continuing to eliminate variables here, as more
>>> than likely some other filter is causing the documents you think should
>>> appear to be filtered out.
>>>
>>> Erik
>>>
>>>
>>>
>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>>
>>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
>>>> q=category_ids_im:(637+OR+639+OR+634)
>>>> it appears to produce the correct results. But... that doesn't seem to
>>> make
>>>> sense to me? Shouldn't it work just fine as a filter query?
>>>> --
>>>> Steven Ou | 歐偉凡
>>>>
>>>> *ravn.com* | Chief Technology Officer
>>>> [EMAIL PROTECTED] | +1 909-569-9880
>>>>
>>>>
>>>> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> I don't really know how to analyze the debug output... Here it is for
>>> the
>>>>> full query I'm running, which includes other filter queries.
>>>>>
>>>>> <lst name="debug">
>>>>> <str name="rawquerystring">*:*</str>
>>>>> <str name="querystring">*:*</str>
>>>>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>>>>> <str name="parsedquery_toString">*:*</str>
>>>>> <lst name="explain"/>
>>>>> <str name="QParser">LuceneQParser</str>
>>>>> <arr name="filter_queries">
>>>>> <str>type:Event</str>
>>>>> <str>displayable_b:true</str>
>>>>> <str>category_ids_im:(637 OR 639 OR 634)</str>
>>>>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>>>>> <str>{!geofilt}</str>
>>>>> </arr>
>>>>> <arr name="parsed_filter_queries">
>>>>> <str>type:Event</str>
>>>>> <str>displayable_b:true</str>
>>>>> <str>
>>>>> category_ids_im:637 category_ids_im:639 category_ids_im:634
>>>>> </str>
>>>>> <str>end_datetime_dt:[1328833072000 TO *]</str>
>>>>> <str>
>>>>>
>>>>>
>>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>>>>> </str>
>>>>> </arr>
>>>>> <lst name="timing">
>>>>> <double name="time">1.0</double>
>>>>> <lst name="prepare">
>>>>> <double name="time">1.0</double
Hmmm... other things to try:
* query on an explicit category, rather than in a boolean expression
* try a different field type than sint (say just int, or string)
* shouldn't matter (since you're using "OR" explicitly) but double check the default operator in schema.xml
* reindex (was the field type ever changed mid-stream?)
Definitely something fishy here. Nothing obvious pops out yet.
Erik
On Feb 9, 2012, at 19:53 , Steven Ou wrote:
> Actually, I take that back. Using q instead of fq still produces the same
> problem. Somehow it's *less* inconsistent so at first glance it looked like
> it fixed it. However, it does *not* fix it :(
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>
>> Well, keeping all other filter queries the same, changing fq>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
>> causes results to not show up.
>>
>> In fact, I took out *all* other filter queries. And while I wasn't able
>> to reproduce it exactly, nonetheless when I added the third category id the
>> number of results *went down*. Which is consistently inconsistent, per
>> se. Adding an OR cannot, logically, reduce the number of results!
>> --
>> Steven Ou | 歐偉凡
>>
>> *ravn.com* | Chief Technology Officer
>> [EMAIL PROTECTED] | +1 909-569-9880
>>
>>
>>
>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]>wrote:
>>
>>> Yes, certainly should work fine as a filter query... I was merely trying
>>> to eliminate variables from the equation. You've got several filters and a
>>> q=*:* going on below, so it's obviously harder to pinpoint what could be
>>> going wrong. I suggest continuing to eliminate variables here, as more
>>> than likely some other filter is causing the documents you think should
>>> appear to be filtered out.
>>>
>>> Erik
>>>
>>>
>>>
>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>>
>>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
>>>> q=category_ids_im:(637+OR+639+OR+634)
>>>> it appears to produce the correct results. But... that doesn't seem to
>>> make
>>>> sense to me? Shouldn't it work just fine as a filter query?
>>>> --
>>>> Steven Ou | 歐偉凡
>>>>
>>>> *ravn.com* | Chief Technology Officer
>>>> [EMAIL PROTECTED] | +1 909-569-9880
>>>>
>>>>
>>>> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> I don't really know how to analyze the debug output... Here it is for
>>> the
>>>>> full query I'm running, which includes other filter queries.
>>>>>
>>>>> <lst name="debug">
>>>>> <str name="rawquerystring">*:*</str>
>>>>> <str name="querystring">*:*</str>
>>>>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>>>>> <str name="parsedquery_toString">*:*</str>
>>>>> <lst name="explain"/>
>>>>> <str name="QParser">LuceneQParser</str>
>>>>> <arr name="filter_queries">
>>>>> <str>type:Event</str>
>>>>> <str>displayable_b:true</str>
>>>>> <str>category_ids_im:(637 OR 639 OR 634)</str>
>>>>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
>>>>> <str>{!geofilt}</str>
>>>>> </arr>
>>>>> <arr name="parsed_filter_queries">
>>>>> <str>type:Event</str>
>>>>> <str>displayable_b:true</str>
>>>>> <str>
>>>>> category_ids_im:637 category_ids_im:639 category_ids_im:634
>>>>> </str>
>>>>> <str>end_datetime_dt:[1328833072000 TO *]</str>
>>>>> <str>
>>>>>
>>>>>
>>> SpatialDistanceQuery(geofilt(latlonSource=coordinates_lls(double(coordinates_lls_0_coordinate),double(coordinates_lls_1_coordinate)),latCenter=37.7561438,lonCenter=-122.4325682,dist=50.0,latMin=37.30648363225355,latMax=38.20580396774645,lonMin=-123.0013021058511,lonMax-121.86383429414894,lon2Min=-180.0,lon2Max180.0,calcDist=true,planetRadius=6371.009))
>>>>> </str>
>>>>> </arr>
>>>>> <lst name="timing">
>>>>> <double name="time">1.0</double>
>>>>> <lst name="prepare">
>>>>> <double name="time">1.0</double
+
Erik Hatcher 2012-02-10, 01:01
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 01:11
Sorry, what do you mean "explicit category rather than boolean expression"?
Type was not changed midstream - hasn't really been changed ever, really.
And I happen to have *just* reindexed, too.
Don't seem to have a default operator set. Not sure how to do it, either...?
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 5:01 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Extremely odd.
>
> Hmmm... other things to try:
>
> * query on an explicit category, rather than in a boolean expression
> * try a different field type than sint (say just int, or string)
> * shouldn't matter (since you're using "OR" explicitly) but double check
> the default operator in schema.xml
> * reindex (was the field type ever changed mid-stream?)
>
> Definitely something fishy here. Nothing obvious pops out yet.
>
> Erik
>
>
> On Feb 9, 2012, at 19:53 , Steven Ou wrote:
>
> > Actually, I take that back. Using q instead of fq still produces the same
> > problem. Somehow it's *less* inconsistent so at first glance it looked
> like
> > it fixed it. However, it does *not* fix it :(
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >
> >> Well, keeping all other filter queries the same, changing fq> >> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> >> causes results to not show up.
> >>
> >> In fact, I took out *all* other filter queries. And while I wasn't able
> >> to reproduce it exactly, nonetheless when I added the third category id
> the
> >> number of results *went down*. Which is consistently inconsistent, per
> >> se. Adding an OR cannot, logically, reduce the number of results!
> >> --
> >> Steven Ou | 歐偉凡
> >>
> >> *ravn.com* | Chief Technology Officer
> >> [EMAIL PROTECTED] | +1 909-569-9880
> >>
> >>
> >>
> >> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]
> >wrote:
> >>
> >>> Yes, certainly should work fine as a filter query... I was merely
> trying
> >>> to eliminate variables from the equation. You've got several filters
> and a
> >>> q=*:* going on below, so it's obviously harder to pinpoint what could
> be
> >>> going wrong. I suggest continuing to eliminate variables here, as more
> >>> than likely some other filter is causing the documents you think should
> >>> appear to be filtered out.
> >>>
> >>> Erik
> >>>
> >>>
> >>>
> >>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> >>>
> >>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> >>>> q=category_ids_im:(637+OR+639+OR+634)
> >>>> it appears to produce the correct results. But... that doesn't seem to
> >>> make
> >>>> sense to me? Shouldn't it work just fine as a filter query?
> >>>> --
> >>>> Steven Ou | 歐偉凡
> >>>>
> >>>> *ravn.com* | Chief Technology Officer
> >>>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>>
> >>>>
> >>>> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> I don't really know how to analyze the debug output... Here it is for
> >>> the
> >>>>> full query I'm running, which includes other filter queries.
> >>>>>
> >>>>> <lst name="debug">
> >>>>> <str name="rawquerystring">*:*</str>
> >>>>> <str name="querystring">*:*</str>
> >>>>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> >>>>> <str name="parsedquery_toString">*:*</str>
> >>>>> <lst name="explain"/>
> >>>>> <str name="QParser">LuceneQParser</str>
> >>>>> <arr name="filter_queries">
> >>>>> <str>type:Event</str>
> >>>>> <str>displayable_b:true</str>
> >>>>> <str>category_ids_im:(637 OR 639 OR 634)</str>
> >>>>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> >>>>> <str>{!geofilt}</str>
> >>>>> </arr>
> >>>>> <arr name="parsed_filter_queries">
> >>>>> <str>type:Event</str>
> >>>>> <str>displayable_b:true</str>
> >>>>> <str>
> >>>>> category_ids_im:637 category_ids_im:639 category_ids_im:634
Type was not changed midstream - hasn't really been changed ever, really.
And I happen to have *just* reindexed, too.
Don't seem to have a default operator set. Not sure how to do it, either...?
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 5:01 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Extremely odd.
>
> Hmmm... other things to try:
>
> * query on an explicit category, rather than in a boolean expression
> * try a different field type than sint (say just int, or string)
> * shouldn't matter (since you're using "OR" explicitly) but double check
> the default operator in schema.xml
> * reindex (was the field type ever changed mid-stream?)
>
> Definitely something fishy here. Nothing obvious pops out yet.
>
> Erik
>
>
> On Feb 9, 2012, at 19:53 , Steven Ou wrote:
>
> > Actually, I take that back. Using q instead of fq still produces the same
> > problem. Somehow it's *less* inconsistent so at first glance it looked
> like
> > it fixed it. However, it does *not* fix it :(
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >
> >> Well, keeping all other filter queries the same, changing fq> >> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> >> causes results to not show up.
> >>
> >> In fact, I took out *all* other filter queries. And while I wasn't able
> >> to reproduce it exactly, nonetheless when I added the third category id
> the
> >> number of results *went down*. Which is consistently inconsistent, per
> >> se. Adding an OR cannot, logically, reduce the number of results!
> >> --
> >> Steven Ou | 歐偉凡
> >>
> >> *ravn.com* | Chief Technology Officer
> >> [EMAIL PROTECTED] | +1 909-569-9880
> >>
> >>
> >>
> >> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]
> >wrote:
> >>
> >>> Yes, certainly should work fine as a filter query... I was merely
> trying
> >>> to eliminate variables from the equation. You've got several filters
> and a
> >>> q=*:* going on below, so it's obviously harder to pinpoint what could
> be
> >>> going wrong. I suggest continuing to eliminate variables here, as more
> >>> than likely some other filter is causing the documents you think should
> >>> appear to be filtered out.
> >>>
> >>> Erik
> >>>
> >>>
> >>>
> >>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> >>>
> >>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> >>>> q=category_ids_im:(637+OR+639+OR+634)
> >>>> it appears to produce the correct results. But... that doesn't seem to
> >>> make
> >>>> sense to me? Shouldn't it work just fine as a filter query?
> >>>> --
> >>>> Steven Ou | 歐偉凡
> >>>>
> >>>> *ravn.com* | Chief Technology Officer
> >>>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>>
> >>>>
> >>>> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> I don't really know how to analyze the debug output... Here it is for
> >>> the
> >>>>> full query I'm running, which includes other filter queries.
> >>>>>
> >>>>> <lst name="debug">
> >>>>> <str name="rawquerystring">*:*</str>
> >>>>> <str name="querystring">*:*</str>
> >>>>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
> >>>>> <str name="parsedquery_toString">*:*</str>
> >>>>> <lst name="explain"/>
> >>>>> <str name="QParser">LuceneQParser</str>
> >>>>> <arr name="filter_queries">
> >>>>> <str>type:Event</str>
> >>>>> <str>displayable_b:true</str>
> >>>>> <str>category_ids_im:(637 OR 639 OR 634)</str>
> >>>>> <str>end_datetime_dt:[2012\-02\-10T00\:17\:52Z TO *]</str>
> >>>>> <str>{!geofilt}</str>
> >>>>> </arr>
> >>>>> <arr name="parsed_filter_queries">
> >>>>> <str>type:Event</str>
> >>>>> <str>displayable_b:true</str>
> >>>>> <str>
> >>>>> category_ids_im:637 category_ids_im:639 category_ids_im:634
+
Steven Ou 2012-02-10, 01:11
-
Re: Empty results with OR filter queryErik Hatcher 2012-02-10, 01:14
On Feb 9, 2012, at 20:11 , Steven Ou wrote:
> Sorry, what do you mean "explicit category rather than boolean expression"?
q=category_ids_im:634 for example. Just to get an idea of what matches each category.
> Type was not changed midstream - hasn't really been changed ever, really.
> And I happen to have *just* reindexed, too.
>
> Don't seem to have a default operator set. Not sure how to do it, either...?
Look at Solr's example schema.xml. It'll have it spelled out there.
Erik
> --
> Steven Ou | 歐偉凡
>
> *ravn.com* | Chief Technology Officer
> [EMAIL PROTECTED] | +1 909-569-9880
>
>
> On Thu, Feb 9, 2012 at 5:01 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
>
>> Extremely odd.
>>
>> Hmmm... other things to try:
>>
>> * query on an explicit category, rather than in a boolean expression
>> * try a different field type than sint (say just int, or string)
>> * shouldn't matter (since you're using "OR" explicitly) but double check
>> the default operator in schema.xml
>> * reindex (was the field type ever changed mid-stream?)
>>
>> Definitely something fishy here. Nothing obvious pops out yet.
>>
>> Erik
>>
>>
>> On Feb 9, 2012, at 19:53 , Steven Ou wrote:
>>
>>> Actually, I take that back. Using q instead of fq still produces the same
>>> problem. Somehow it's *less* inconsistent so at first glance it looked
>> like
>>> it fixed it. However, it does *not* fix it :(
>>> --
>>> Steven Ou | 歐偉凡
>>>
>>> *ravn.com* | Chief Technology Officer
>>> [EMAIL PROTECTED] | +1 909-569-9880
>>>
>>>
>>> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>>
>>>> Well, keeping all other filter queries the same, changing fq>>>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
>>>> causes results to not show up.
>>>>
>>>> In fact, I took out *all* other filter queries. And while I wasn't able
>>>> to reproduce it exactly, nonetheless when I added the third category id
>> the
>>>> number of results *went down*. Which is consistently inconsistent, per
>>>> se. Adding an OR cannot, logically, reduce the number of results!
>>>> --
>>>> Steven Ou | 歐偉凡
>>>>
>>>> *ravn.com* | Chief Technology Officer
>>>> [EMAIL PROTECTED] | +1 909-569-9880
>>>>
>>>>
>>>>
>>>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]
>>> wrote:
>>>>
>>>>> Yes, certainly should work fine as a filter query... I was merely
>> trying
>>>>> to eliminate variables from the equation. You've got several filters
>> and a
>>>>> q=*:* going on below, so it's obviously harder to pinpoint what could
>> be
>>>>> going wrong. I suggest continuing to eliminate variables here, as more
>>>>> than likely some other filter is causing the documents you think should
>>>>> appear to be filtered out.
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
>>>>>
>>>>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
>>>>>> q=category_ids_im:(637+OR+639+OR+634)
>>>>>> it appears to produce the correct results. But... that doesn't seem to
>>>>> make
>>>>>> sense to me? Shouldn't it work just fine as a filter query?
>>>>>> --
>>>>>> Steven Ou | 歐偉凡
>>>>>>
>>>>>> *ravn.com* | Chief Technology Officer
>>>>>> [EMAIL PROTECTED] | +1 909-569-9880
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 9, 2012 at 4:20 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> I don't really know how to analyze the debug output... Here it is for
>>>>> the
>>>>>>> full query I'm running, which includes other filter queries.
>>>>>>>
>>>>>>> <lst name="debug">
>>>>>>> <str name="rawquerystring">*:*</str>
>>>>>>> <str name="querystring">*:*</str>
>>>>>>> <str name="parsedquery">MatchAllDocsQuery(*:*)</str>
>>>>>>> <str name="parsedquery_toString">*:*</str>
>>>>>>> <lst name="explain"/>
>>>>>>> <str name="QParser">LuceneQParser</str>
>>>>>>> <arr name="filter_queries">
>>>>>>> <str>type:Event</str>
>>>>>>> <str>displayable_b:true</str>
>>>>>>> <str>category_ids_im:(637 OR 639 OR 634)</str>
+
Erik Hatcher 2012-02-10, 01:14
-
Re: Empty results with OR filter querySteven Ou 2012-02-10, 19:08
For anyone having this issue in the future:
I managed to narrow it down to Solr-RA 3.5. Installing Solr 3.5 solved the
issue. I don't really know how the internals of Solr-RA work, but it
appears that it was using AND operators even when I explicitly used OR
operators in the query. The other solution was to set defaultOperator to
OR, but I wasn't sure how this would affect my other queries. Would
explicit AND operators now become OR operators?
Anyway, thanks to Erik for helping me troubleshoot this!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 5:14 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
>
> On Feb 9, 2012, at 20:11 , Steven Ou wrote:
>
> > Sorry, what do you mean "explicit category rather than boolean
> expression"?
>
> q=category_ids_im:634 for example. Just to get an idea of what matches
> each category.
>
> > Type was not changed midstream - hasn't really been changed ever, really.
> > And I happen to have *just* reindexed, too.
> >
> > Don't seem to have a default operator set. Not sure how to do it,
> either...?
>
> Look at Solr's example schema.xml. It'll have it spelled out there.
>
> Erik
>
>
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 5:01 PM, Erik Hatcher <[EMAIL PROTECTED]>
> wrote:
> >
> >> Extremely odd.
> >>
> >> Hmmm... other things to try:
> >>
> >> * query on an explicit category, rather than in a boolean expression
> >> * try a different field type than sint (say just int, or string)
> >> * shouldn't matter (since you're using "OR" explicitly) but double check
> >> the default operator in schema.xml
> >> * reindex (was the field type ever changed mid-stream?)
> >>
> >> Definitely something fishy here. Nothing obvious pops out yet.
> >>
> >> Erik
> >>
> >>
> >> On Feb 9, 2012, at 19:53 , Steven Ou wrote:
> >>
> >>> Actually, I take that back. Using q instead of fq still produces the
> same
> >>> problem. Somehow it's *less* inconsistent so at first glance it looked
> >> like
> >>> it fixed it. However, it does *not* fix it :(
> >>> --
> >>> Steven Ou | 歐偉凡
> >>>
> >>> *ravn.com* | Chief Technology Officer
> >>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>
> >>>
> >>> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Well, keeping all other filter queries the same, changing fq> >>>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> >>>> causes results to not show up.
> >>>>
> >>>> In fact, I took out *all* other filter queries. And while I wasn't
> able
> >>>> to reproduce it exactly, nonetheless when I added the third category
> id
> >> the
> >>>> number of results *went down*. Which is consistently inconsistent, per
> >>>> se. Adding an OR cannot, logically, reduce the number of results!
> >>>> --
> >>>> Steven Ou | 歐偉凡
> >>>>
> >>>> *ravn.com* | Chief Technology Officer
> >>>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]
> >>> wrote:
> >>>>
> >>>>> Yes, certainly should work fine as a filter query... I was merely
> >> trying
> >>>>> to eliminate variables from the equation. You've got several filters
> >> and a
> >>>>> q=*:* going on below, so it's obviously harder to pinpoint what could
> >> be
> >>>>> going wrong. I suggest continuing to eliminate variables here, as
> more
> >>>>> than likely some other filter is causing the documents you think
> should
> >>>>> appear to be filtered out.
> >>>>>
> >>>>> Erik
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> >>>>>
> >>>>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> >>>>>> q=category_ids_im:(637+OR+639+OR+634)
> >>>>>> it appears to produce the correct results. But... that doesn't seem
> to
> >>>>> make
> >>>>>> sense to me? Shouldn't it work just fine as a filter query?
I managed to narrow it down to Solr-RA 3.5. Installing Solr 3.5 solved the
issue. I don't really know how the internals of Solr-RA work, but it
appears that it was using AND operators even when I explicitly used OR
operators in the query. The other solution was to set defaultOperator to
OR, but I wasn't sure how this would affect my other queries. Would
explicit AND operators now become OR operators?
Anyway, thanks to Erik for helping me troubleshoot this!
--
Steven Ou | 歐偉凡
*ravn.com* | Chief Technology Officer
[EMAIL PROTECTED] | +1 909-569-9880
On Thu, Feb 9, 2012 at 5:14 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote:
>
> On Feb 9, 2012, at 20:11 , Steven Ou wrote:
>
> > Sorry, what do you mean "explicit category rather than boolean
> expression"?
>
> q=category_ids_im:634 for example. Just to get an idea of what matches
> each category.
>
> > Type was not changed midstream - hasn't really been changed ever, really.
> > And I happen to have *just* reindexed, too.
> >
> > Don't seem to have a default operator set. Not sure how to do it,
> either...?
>
> Look at Solr's example schema.xml. It'll have it spelled out there.
>
> Erik
>
>
> > --
> > Steven Ou | 歐偉凡
> >
> > *ravn.com* | Chief Technology Officer
> > [EMAIL PROTECTED] | +1 909-569-9880
> >
> >
> > On Thu, Feb 9, 2012 at 5:01 PM, Erik Hatcher <[EMAIL PROTECTED]>
> wrote:
> >
> >> Extremely odd.
> >>
> >> Hmmm... other things to try:
> >>
> >> * query on an explicit category, rather than in a boolean expression
> >> * try a different field type than sint (say just int, or string)
> >> * shouldn't matter (since you're using "OR" explicitly) but double check
> >> the default operator in schema.xml
> >> * reindex (was the field type ever changed mid-stream?)
> >>
> >> Definitely something fishy here. Nothing obvious pops out yet.
> >>
> >> Erik
> >>
> >>
> >> On Feb 9, 2012, at 19:53 , Steven Ou wrote:
> >>
> >>> Actually, I take that back. Using q instead of fq still produces the
> same
> >>> problem. Somehow it's *less* inconsistent so at first glance it looked
> >> like
> >>> it fixed it. However, it does *not* fix it :(
> >>> --
> >>> Steven Ou | 歐偉凡
> >>>
> >>> *ravn.com* | Chief Technology Officer
> >>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>
> >>>
> >>> On Thu, Feb 9, 2012 at 4:48 PM, Steven Ou <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> Well, keeping all other filter queries the same, changing fq> >>>> category_ids_im:(637+OR+639) to fq=category_ids_im:(637+OR+639+OR+634)
> >>>> causes results to not show up.
> >>>>
> >>>> In fact, I took out *all* other filter queries. And while I wasn't
> able
> >>>> to reproduce it exactly, nonetheless when I added the third category
> id
> >> the
> >>>> number of results *went down*. Which is consistently inconsistent, per
> >>>> se. Adding an OR cannot, logically, reduce the number of results!
> >>>> --
> >>>> Steven Ou | 歐偉凡
> >>>>
> >>>> *ravn.com* | Chief Technology Officer
> >>>> [EMAIL PROTECTED] | +1 909-569-9880
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Feb 9, 2012 at 4:39 PM, Erik Hatcher <[EMAIL PROTECTED]
> >>> wrote:
> >>>>
> >>>>> Yes, certainly should work fine as a filter query... I was merely
> >> trying
> >>>>> to eliminate variables from the equation. You've got several filters
> >> and a
> >>>>> q=*:* going on below, so it's obviously harder to pinpoint what could
> >> be
> >>>>> going wrong. I suggest continuing to eliminate variables here, as
> more
> >>>>> than likely some other filter is causing the documents you think
> should
> >>>>> appear to be filtered out.
> >>>>>
> >>>>> Erik
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Feb 9, 2012, at 19:24 , Steven Ou wrote:
> >>>>>
> >>>>>> By turning fq=category_ids_im:(637+OR+639+OR+634) to
> >>>>>> q=category_ids_im:(637+OR+639+OR+634)
> >>>>>> it appears to produce the correct results. But... that doesn't seem
> to
> >>>>> make
> >>>>>> sense to me? Shouldn't it work just fine as a filter query?
+
Steven Ou 2012-02-10, 19:08
