I agree about SpanQueries. It's a viable measure against "false-positive matches on multivalue fields". we've implemented this approach some time ago. Pls find details at http://blog.griddynamics.com/2011/06/solr-experience-search-parent-child.html
and http://blog.griddynamics.com/2011/07/solr-experience-search-parent-child.html we are going to publish the third post about an implementation approaches. -- Mikhail Khludnev On Sat, Oct 1, 2011 at 6:25 AM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : Another, faulty, option would be to model opening/closing hours in 2 > : multivalued date-fields, i.e: open, close. and insert open/close for each > : day, e.g: > : > : 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: > > This isn't possible out of the box, but the general idea of "position > linked" queries is possible using the same approach as the > FieldMaskingSpanQuery... > > > https://lucene.apache.org/java/3_4_0/api/core/org/apache/lucene/search/spans/FieldMaskingSpanQuery.html > https://issues.apache.org/jira/browse/LUCENE-1494 > > ..implementing something like this that would work with > (Numeric)RangeQueries however would require some additional work, but it > should certianly be doable -- i've suggested this before but no one has > taken me up on it... > http://markmail.org/search/?q=hoss+FieldMaskingSpanQuery > > If we take it as a given that you can do multiple ranges "at the same > position", then you can imagine supporting all of your "regular" hours > using just two fields ("open" and "close") by encoding the day+time of > each range of open hours into them -- even if a store is open for multiple > sets of ranges per day (ie: closed for siesta)... > > open: mon_12_30, tue_12_30, wed_07_30, wed_3_30, ... > close: mon_20_00, tue_20_30, wed_12_30, wed_22_30, ... > > then asking for "stores open now and for the next 3 hours" on "wed" at > "2:13PM" becomes a query for... > > sameposition(open:[* TO wed_14_13], close:[wed_17_13 TO *]) > > For the special case part of your problem when there are certain dates > that a store will be open atypical hours, i *think* that could be solved > using some special docs and the new "join" QParser in a filter query... > > https://wiki.apache.org/solr/Join > > imagine you have your "regular" docs with all the normal data about a > store, and the open/close fields i describe above. but in addition to > those, for any store that you know is "closed on dec 25" or "only open > 12:00-15:00 on Jan 01" you add an additional small doc encapsulating > the information about the stores closures on that special date - so that > each special case would be it's own doc, even if one store had 5 days > where there was a special case... > > specialdoc1: > store_id: 42 > special_date: Dec-25 > status: closed > specialdoc2: > store_id: 42 > special_date: Jan-01 > status: irregular > open: 09_30 > close: 13_00 > > then when you are executing your query, you use an "fq" to constrain to > stores that are (normally) open right now (like i mentioned above) and you > use another fq to find all docs *except* those resulting from a join > against these special case docs based on the current date. > > so if you r query is "open now and for the next 3 hours" and "now" == > "sunday, 2011-12-25 @ 10:17AM your query would be something like... > > q=...user input... > time=sameposition(open:[* TO sun_10_17], close:[sun_13_17 TO *]) > fq={!v=time} > fq={!join from=store_id to=unique_key v=$vv} > vv=-(+special_date:Dec-25 +(status:closed OR _query_:"{v=$time}")) > > That join based approach for dealing with the special dates should work > regardless of wether someone implements a way to do pair wise > "sameposition()" rangequeries ... so if you can live w/o the multiple > open/close pairs per day, you can just use the "one field per day of hte > week" type approach you mentioned combined with the "join" for special > case days of hte year and everything you need should already work w/o any > code (on trunk). > > (disclaimer: obviously i haven't tested that query, the exact syntax may > be off but the princible for modeling the "special docs" and using > them in a join should work) > > > -Hoss > -- Sincerely yours Mikhail (Mike) Khludnev Developer Grid Dynamics tel. 1-415-738-8644 Skype: mkhludnev <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
