lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: multiple dateranges/timeslots per doc: modeling openinghours.
Date Sat, 01 Oct 2011 02:25:44 GMT

: 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

Mime
View raw message