Hi Britske, This is a very interesting question!
britske wrote > ... > I realize the new spatial-stuff in Solr 4 is no magic bullet, but I'm > wondering if I could model multiple prices per day as multipoints, > whereas: > > - date*duration*nr of persons*roomtype is modeled as point.x (discretized > in some 20.000 values) > - price modeled as point.y ( in dollarcents / normalized as avg price per > day: range: [0,200000] covering a max price of $2.000/day) > > The stuff that needs to be possible: > A) 1 required filter on point.x (filtering a 1 particular > <date*duration*nr of persons* roomtype> combo. > B) an optional range query on point.y (min and./or max price filter) > C) optional soring on point.y (sorting on price (normal or reverse)) > > I'm pretty certain A) and B) won't be a problem as far is functionality is > concerned, but how about performance? I.e: would some sort of cached Solr > filter jump in for a given <date*duration*nr of persons* roomtype> > combo, for quick doc-interesection, just as would with multiple dynamic > fields in my desribed as-is-case? A & B are indeed not a problem and there are no special caches / memory requirements inherent in this. britske wrote > How about C)? Is sorting on point.y possible? (potenially in conjunction > with other sorting-fields used as tiebreaker, to give a stable sort? I > remember to have read that any filterquery can be used for sorting > combined with multipoints (which would make the above work I guess) but > just would like to confirm. > ... 'C' (sorting) is the challenge. As it stands, you will have to implement a variation of this class: http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/lucene/spatial/src/java/org/apache/lucene/spatial/util/ShapeFieldCacheDistanceValueSource.java?view=markup Unlike this implementation, your implementation should ensure the point is indeed in the query shape, and it should be configured to take the smallest or largest 'y' as desired. Note that the cache infrastructure that this is built on is flakey right now -- a memory hog in multiple ways. There will be a Point implementation in memory for all of your indexed points, and an ArrayList per doc. And it's not NRT search friendly, and doesn't relinquish its resources (i.e. on commit) as quickly as it should. I know what it's problems are but I have been quite busy. ~ David ----- 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-tp4026011p4026151.html Sent from the Solr - User mailing list archive at Nabble.com.
