2012/12/12 David Smiley (@MITRE.org) <dsmi...@mitre.org> > britske wrote > > Hi David, > > > > Yeah interesting (as well as problematic as far is implementing) use-case > > indeed :) > > > > 1. You mention "there are no special caches / memory requirements > inherent > > in this.". For a given user-query this would mean all hotels would have > to > > seach for all point.x each time right? What would be a good plugin-point > > to > > build in some custom cached filter code for this (perhaps using the Solr > > Filter cache)? As I see it, determining all hotels that have a particular > > point.x value is probably: A) pretty costly to do on each user query. B). > > is static and can be cached easily without a lot of memory (relatively > > speaking) i.e: 20.000 filters (representing all of the 20.000 different > > point.x, that is, <date,duration,nr persons, roomtype> combos) with > > a > > bitset per filter representing ids of hotels that have the said point.x. > > I think you're over-thinking the complexity of this query. I bet it's > faster than you think and even then putting this in a filter query 'fq' is > going to be cached by Solr any way, making it lightning fast at subsequent > queries. > > Ah! Didn't realize such a spatial query could be dropped in a FQ. Nice, that solves this part indeed.
> britske wrote > > 2. I'm not sure I explained C. (sorting) well, since I believe you're > > talking about implementing custom code to sort multiple point.y's per > > hotel, correct?. That's not what I need. Instead, for every user-query at > > most 1 point ever matches. I.e: a hotel has a price for a particular > > <date, > > duration,nrpersons,roomtype>-combo (P.x) or it hasn't. > > > > Say a user queries for the > <date,duration,nrpersons,roomtype>-combo: > > <21 > > dec 2012,3 days,2 persons, double>. This might be encoded into a value, > > say: 12345. > > Now, for the hotels that do match that query (i.e: those hotels that have > > a > > point P for which P.x=12345) I want to sort those hotels on P.y (the > price > > for the requested P.x) > > Ah; ok. But still, my first suggestion is still what I think you could do > except that the algorithm is simpler -- return the first matching 'y' in > the > document where the point matches the query. Alternatively, if you're > confident the number of matching documents (hotels) is going to be > small-ish, say less than a couple hundred, then you could simply sort it > client-side. You'd have to get back all the values, or maybe write a > DocTransformer to find the specific one. > > ~ David > > Writing something similar to ShapeFieldCacheDistanceValueSource, being a valueSource, would enable me to expose it by name to the frontend? What I'm saying is: let's say I want to call this implementation 'pricesort' and chain it with other sorts, like: 'sort=pricesort asc, popularity desc, name asc'. Or use it by name in a functionquery. That would be possible right? Geert-Jan > > ----- > Author: > http://www.packtpub.com/apache-solr-3-enterprise-search-server/book > -- > View this message in context: > http://lucene.472066.n3.nabble.com/modeling-prices-based-on-daterange-using-multipoints-tp4026011p4026256.html > Sent from the Solr - User mailing list archive at Nabble.com. >
