: I've not yet used dynamic fields in this manner. With that number range, : what limitations could I encounter? Given the size of that, I would need
very little, yonik recently listed the "costs" of dynamic fields... http://www.nabble.com/Searching-multiple-indices-%28solr-newbie%29-tf2903899.html#a8245621 ..as he points out, with omitNorms="true" you can have thousands of dynamic fields and not even notice. : the solr engine to formulate that query, correct? I can't imagine I could : pass that entire subquery statement in the http request, as the character : limit would likely be exceeded. yeah ... if you wanted to try the approach i described, and your "N" wasn't a single digit number, i would recommend putting the query building code into a custom RequestHandler ... it could even inspect the list of field names from the IndexReader and know exactly how big N is at any given moment. i have no idea how efficient this approach would be if N really does get up into the hundreds. A completely different approach you could take if you want to get into Lucene Query internals would be to take advantage of something Doug mentioned once that has stayed in the back of my mind for almost a year now: PhraseQuery artificially enforces that the Terms you add to it are in the same field ... you could easily write a PhraseQuery-ish query that takes Terms from differnet fields, and ensures that they appear "near" eachother in terms of their token sequence -- the context of that comment was searching for instances of words with specific usage (ie: "house" used as a noun) by putting the usage type of each term in a different term in a seperate parallel field, but with identicle token positions. if you forget for a moment about the ranges you need to do, and imagine instead that you store the "quadrent number" and "hour of day" for each event, where e1q is the quadtrent of event1 for an item, and e1h is the hour of the day that event1 happened at, then for an item with multiple events you could index the field/terms lists quadrent: e1q e2q e3q hour: e1h e2h e3h and query for your input quadrent at a term position equal to the term position of your input hour. if you got *that* working, you could concievably change the query to take in a range for each field -- using TermEnum to get the list of of all latitude Terms in your latitude range, then for each of those Terms get the list of documents and the term position within thta document, and then look for the longitude terms in the same relative term position which are in your longitude range, and time terms in the same relative term position in your time range. does that make any sense? this is all purely theoretical, it just seems like it *should* be possible, but i haven't thought through how it would be implimented. if you acctually wanted to tackle it, i would start a discussion on [EMAIL PROTECTED] first, so people smarter then me can tlel you if i'm smoking crack or not. -Hoss
