此Solr范围过滤器查询出了什么问题? [英] What's wrong with this Solr range filter query?

查看:184
本文介绍了此Solr范围过滤器查询出了什么问题?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

以下过滤器查询返回零结果(使用*:*作为查询):

The following filter query returns zero results (using *:* as query):

-startDate:[* TO *] OR startDate:[* TO NOW/DAY+1DAY]

但是,如果我仅按以下条件进行过滤:

But if I filter only by:

-startDate:[* TO *]

我得到3个结果.

如果仅按以下条件过滤

startDate:[* TO NOW/DAY+1DAY]

我得到161个结果.

为什么合并的FQ返回零结果?我想要的是过滤器,以返回开始日期为null或开始日期在今天之前的任何文档.

Why is the combined FQ returning zero results? What I want is the filter to return any doc whose start date is null or start date is before today.

我正在使用Solr 4.2.1.2013.03.26.08.26.55

I'm using Solr 4.2.1.2013.03.26.08.26.55

很奇怪,这听起来像是一位同事建议在两个部分上加上括号:

Well, strange it may sound a colleague suggested putting parenthesis on the two parts like this:

(-startDate:[* TO *]) OR (startDate:[* TO NOW/DAY+1DAY])

它以某种方式起作用.我仍然很好奇为什么会有所作为.希望有人可以照亮.

And somehow it worked. I'm still curious why that made a difference. Hope someone can shed some light.

谢谢!

推荐答案

Solr支持纯否定查询.他们实质上是通过将纯负数扩展为类似以下内容来实现这一点的:

Solr supports pure negative queries. They do this, essentially, by expanding the pure negative to something like:

*:* -startDate:[* TO *]

但是,将其组合到BooleanQuery中时,我认为它不再应用这种逻辑.在Lucene中,否定查询不会获取任何内容,而是过滤掉其他正查询条件带来的匹配项.这与SQL查询不同,SQL查询在某种意义上以隐式*:*开头或完整的结果表,并允许您对其进行缩减.

However, what you combine it in a BooleanQuery, I don't believe it applies this sort of logic anymore. A negative query does not, in lucene, fetch anything, but rather filters out matches brought in by other, positive, query terms. This differs from SQL queries, which in a sense start with an implicit *:*, or a full table of results, and allow you to pare it down.

我相信您的OR被有效地忽略了,因为严格来说,它在上下文中没有意义.通常,我相信OR只是语法糖(field:this OR field:that等同于field:this field:that).

I believe your OR is effectively being ignored, since it doesn't, strictly speaking, make sense in context. Generally, OR is just syntactic sugar, I believe (field:this OR field:that is equivalent to field:this field:that).

因此,实际上您的查询是:startDate:[* TO NOW/DAY+1DAY] -startDate:[* TO *],这使您看到的结果更加明显.将其括在圆括号中时,每个词条查询都会被单独处理,并且可以访问solr对孤独否定查询的支持.

So, in effect your query is: startDate:[* TO NOW/DAY+1DAY] -startDate:[* TO *], which makes the results you see more obvious. When you wrap it in parentheses, then each term query is treated separately, and you gain access to solr's support of lonely negative queries.

一个更好的主意是如果需要搜索未设置/空值,则存储默认值. *:*和扩展的纯否定查询必须扫描整个索引,因此效果很差.提供默认值将提高性能,并避免出现这种令人困惑的情况.

A much better idea is to store a default value, if you need to search for unset/null values. *:* and by extension pure negative queries like this have to scan the entire index, and so perform very poorly. Providing a default value will improve performance, and prevent this sort of confusing situation.

这篇关于此Solr范围过滤器查询出了什么问题?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆