考虑一个酒吧可能有多个营业时间，具体取决于星期几（+一些可能关闭的特殊日期）
我希望能够查找当前开放的所有酒吧以及下一个将开放的酒吧，例如， 3小时。 （或者可以问：“2011 年 10 月 18 日从 7 点到（至少）10 点开放”）
我认为最好的事情是为每个日期都有一个“开放、关闭”元组（欢迎其他建议
） ，据我所知？，一种将开盘/收盘时间组合在 1 个字段中的字段类型，我可以天真地（但错误地）使用 2 个字段定义此结构：“开盘”和“闭盘”，这两个字段需要多值的。
现在将它们索引为：
open: 2011-11-08:1800 - close: 2011-11-09:0300
open: 2011-11-09:1700 - close: 2011-11-10:0500
open: 2011-11-10:1700 - close: 2011-11-11:0300
查询的形式为：
open < now && close > now+3h
但由于无法表明“打开”和“关闭”是成对相关的，因此我会得到很多误报，例如上述文档将返回：
open < 2011-11-09:0100 && close > 2011-11-09:0600
因为有些开放日期是在 2011-11-09:0100 之前（即：2011-11-08:1800），而有些关闭日期是在之后2011-11-09:0600（例如：2011-11-11:0300），但这些开盘日期和截止日期不是成对相关的。
我一直在考虑使用 Solr 动态字段的完全不同的方法，其中每个开始和结束日期都有自己的动态字段，例如：
- _date_2011-11-09_open: 1800
- _date_2011-11-09_close: 0300
- _date_2011-11- 09_开放：1700
- _date_2011-11-10_close: 0500
- _date_2011-11-10_open: 1700
- _date_2011-11-11_close: 0300
然后，客户端应该知道要查询的日期，从而知道要查询的正确字段。这可以解决问题，因为 startdate/enddate 也不是成对相关的，但我担心从性能角度来看这可能是一个大问题（特别是 Lucene fieldcache 的内存消耗）
到目前为止，我还没有找到令人满意的解决方案。
非常感谢任何帮助。
Consider a bar which might have multiple openinghours, depending on the day of week (+ some special days when it might be closed)
I want to be able to lookup all bars that are currently open and that will be open for the next, say, 3 hours. (or be able to ask: 'open on 18-10-2011 from 7 until (at least) 10 )
The best thing I believe would be to have a 'open,close'-tuple for each date (other suggestions welcome)
Without, as far as I know ?, a fieldtype that combines open/close hours in 1 field, I can naively (but wrongly) define this structure using 2 fields: 'open' and 'closed', which need to be multivalued.
Now index them like:
open: 2011-11-08:1800 - close: 2011-11-09:0300
open: 2011-11-09:1700 - close: 2011-11-10:0500
open: 2011-11-10:1700 - close: 2011-11-11:0300
And queries would be of the form:
open < now && close > now+3h
But since there is no way to indicate that 'open' and 'close' are pairwise related I will get a lot of false positives, e.g the above document would be returned for:
open < 2011-11-09:0100 && close > 2011-11-09:0600
because SOME opendate is before 2011-11-09:0100 (i.e: 2011-11-08:1800) and SOME closedate is after 2011-11-09:0600 (for example: 2011-11-11:0300) but these open and close-dates are not pairwise related.
I have been thinking about a totally different approach using Solr dynamic fields, in which each and every opening and closing-date gets it's own dynamic field, e.g:
- _date_2011-11-09_open: 1800
- _date_2011-11-09_close: 0300
- _date_2011-11-09_open: 1700
- _date_2011-11-10_close: 0500
- _date_2011-11-10_open: 1700
- _date_2011-11-11_close: 0300
Then, the client should know the date to query, and thus the correct fields to query. This would solve the problem, since startdate/ enddate are nor pairwise -related, but I fear this can be a big issue from a performance standpoint (especially memory consumption of the Lucene fieldcache)
Thusfar, I haven't found a satisfactory solution.
Any help highly appreciated.
发布评论
评论（2）
在像我想要的那样保持 Bars 的粒度（而不是 BarsxDate）的同时，可以使用实验性的 Lucene Spatial Playground 实现。
用例+一般解决方案在这里：
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=comment-13115244#comment- 13115244
While keeping granularity on Bars like I want (instead of BarsxDate) it's possible to use the expirimental Lucene Spatial Playground implementation.
The use-case + general solution is here:
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=comment-13115244#comment-13115244
首先一个问题 - 你们真的有空约会时间吗？不是一周中的几天？但抛开这一点（它不会以任何重要的方式改变答案），您应该做的是为每个柱/日期组合创建一个文档。在每个文档中，您都需要您计划搜索的所有字段；也许包括位置、酒吧名称等。因此这些字段将被非规范化（在许多相关文档中重复）。
这样您就可以执行您所描述的查询并获得精确的结果。
First a question - do you really have open times for dates? not days of the week? but leaving that aside (it doesn't change the answer in any important way), what you should do is create a document for every bar/date combination. In each of these documents you will need all the fields you are planning to search on; maybe that includes location, bar name, etc. So those fields will be denormalized (duplicated across many related documents).
That way you can do the query you describe and get precise results.