Looks like you might be able to use sub-documents (or whatever it is called in SOLR) for this; create the parent document without any dates, and a child document for each date range.
On 01 Mar 2014, at 19:41 , Thomas Scheffler <thomas.scheff...@uni-jena.de> wrote: > Am 01.03.14 18:24, schrieb Erick Erickson: >> I'm not clear what you're really after here. >> >> Solr certainly supports ranges, things like time:[* TO date_spec] or >> date_field:[date_spec TO date_spec] etc. >> >> >> There's also a really creative use of spatial (of all things) to, say >> answer questions involving multiple dates per record. Imagine, for >> instance, employees with different hours on different days. You can >> use spatial to answer questions like "which employees are available >> on Wednesday between 4PM and 8PM". >> >> And if none of this is relevant, how about you give us some >> use-cases? This could well be an XY problem. > > Hi, > > lets try this example to show the problem. You have some old text that was > written in two periods of time: > > 1.) 2nd half of 13th century: -> 1250-1299 > 2.) Beginning of 18th century: -> 1700-1715 > > You are searching for text that were written between 1300-1699, than this > document described above should not be hit. > > If you make start date and end date multiple this results in: > > start: [1250, 1700] > end: [1299, 1715] > > A search for documents written between 1300-1699 would be: > > (+start:[1300 TO 1699] +end:[1300-1699]) (+start:[* TO 1300] +end:[1300 TO > *]) (+start:[*-1699] +end:[1700 TO *]) > > You see that the document above would obviously hit by "(+start:[* TO 1300] > +end:[1300 TO *])" > > Hope you see the problem. This problem is the same when ever you face > multiple ranges in one field of a document. For every duplication you need to > create a separate SOLR document. If you have two such fields in one document, > field "one" with n values and field "two" with m values. You are forced to > create m*n documents. This fact and the rather unhandy query (s.o.) are my > motivation to ask for range types like in PostgreSQL where the problem is > solved. > > regards, > > Thomas
