认为 Sphinx 在使用增量索引时无法排序
我不确定谁错了,但我们的用户表中有一个名为last_logged_in_at的列,我们用它来排序。这是在使用 Thinking Sphinx 且启用了增量索引的 Rails 2.3 项目中。
当记录的 delta 设置为 true 时,即使按 last_logged_in_at 排序应将其放在顶部,它也会被推到底部。
我尝试将last_logged_in_at 设置为日期时间、时间戳甚至整数,并且行为始终相同。
有什么想法吗?
查询看起来像这样:
{:populate=>true,
:match_mode=>:boolean,
:order=>"last_logged_in_at DESC, updated_at DESC",
:per_page=>20,
:with_all=>{:role_id=>17,
:state=>"activated",
:mandator_id=>9,
:profile_active=>true},
:page=>nil}
I'm not sure who is at fault here, but we have a column in our users table called last_logged_in_at that we use for sorting. This is in a Rails 2.3 project using Thinking Sphinx with delta indexes enabled.
When a record has delta set to true, it is push to the bottom even if the sorting by last_logged_in_at should put it at the top.
I tried with last_logged_in_at being a datetime, a timestamp and even an integer and the behavior is always the same.
Any ideas why?
The query looks something like:
{:populate=>true,
:match_mode=>:boolean,
:order=>"last_logged_in_at DESC, updated_at DESC",
:per_page=>20,
:with_all=>{:role_id=>17,
:state=>"activated",
:mandator_id=>9,
:profile_active=>true},
:page=>nil}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
抱歉,生活太忙,回复慢了。
您正在过滤字符串 - Sphinx 目前不允许这样做。不过,有解决这个问题的方法。
另外:您正在使用
:with_all
,但:with
在您的情况下的行为方式完全相同。当您想要匹配单个属性上的多个值时,:with_all
非常有用。例如,此查询将匹配文章具有任何给定标签ID的结果:但是下一个查询匹配具有所有给定标签ID的文章:
我没有意识到这些点与您的问题直接相关 - 但是,最好首先使查询有效,然后仔细检查行为是否正确。
Sorry, life's crazy busy, hence slow reply.
You're filtering on a string - which Sphinx doesn't currently allow. There are ways around this, though.
Also: You're using
:with_all
, but:with
behaves in exactly the same way in your situation.:with_all
is useful when you want to match multiple values on a single attribute. For example, this query will match results where articles have any of the given tag ids:But this next query matches articles with all of the given tag ids:
I realise neither of these points are directly related to your issue - however, it's best to get the query valid first, and then double-check whether the behaviour is correct or not.