What about parent/child record? With availability in the child record? You'd have to reindex the whole block together, but you should be able to get away with one request.
Regards, Alex. No idea on the primary question, as you can probably guess. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 4 December 2014 at 08:24, Mathijs Corten <m.cor...@bedandbreakfast.eu> wrote: > well we though of that but there are some problems with a second core for > availability: > we already have a core containing alot of house information (id, name, > latitude, longitude, city , country etc.) which means we would have to do 2 > solr queries just to build 1 search result or add alot of double information > to the availabillity core (Every availabillity record would also contain id, > name, latitude, longitude etc.). > > I was also reading about joining 2 cores together but the limit on this is > that you can not return information from the second core. > > So of course as second core with availabillity would be a solution it just > isn't our preferred one > > > > On 04-12-14 14:17, Alexandre Rafalovitch wrote: >> >> Have you thought storing 'availability' as a document instead of >> 'house'. So, the house, date range and price are a single document. >> Then, you group them, sum them and in post-filter sort them? >> >> Some ideas may come from: >> >> http://www.slideshare.net/trenaman/personalized-search-on-the-largest-flash-sale-site-in-america >> (though it is quite old by now) >> >> Regards, >> Alex. >> Personal: http://www.outerthoughts.com/ and @arafalov >> Solr resources and newsletter: http://www.solr-start.com/ and @solrstart >> Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 >> >> >> On 4 December 2014 at 05:54, Mathijs Corten <m.cor...@bedandbreakfast.eu> >> wrote: >>> >>> Hello, >>> >>> *Usercase:* >>> At this moment we have the current situation : >>> We have customers that want to rent houses to visitors of our website. >>> Customers can vary the prices according to specific dates, so renting a >>> house at holidays will cost more. >>> >>> *The problems:* >>> - prices may vary according to the dates a visitor of the website >>> specified. >>> - we want SOLR to calculate this total price based on base_price and >>> the >>> price_%DATE% dynamic fields >>> - we want SOLR to sort the result on this total price >>> - we want SOLR to return this price so we can display it on our website >>> >>> *Example:* >>> >>> house_id : 1 >>> base_price = 20 <- base price >>> price_20141225 = 50 <- dynamic field with price for a specified date >>> price_20141226 = 60 <- dynamic field with price for a specified date >>> >>> house_id : 2 >>> base_price = 30 <- base price >>> price_20141229 = 50 <- dynamic field with price for a specified date >>> >>> Lets say a customer wants to rent a house from 2014-12-25 till >>> 2014-12-30, >>> the prices would be calculated at query time like this: >>> House 1: 50 + 60 + 20 + 20 + 20 >>> House 2: 30 + 30 + 30 + 30 + 50 >>> >>> *What **i already got:* >>> I did some researche and made my own SearchComponent, which had a few >>> problems: >>> - total price field that got added kept existing unless i removed it or >>> restarted SOLR <- a problem with multiple search queries at the same time >>> - i could not sort on the totalprice field, field seemed to be unknown. >>> >>> >>> *Now my question is:* >>> Do any of you have any suggestions on how to add a total price field >>> (based >>> on base_price and dynamic fields), sort on it and return it to our >>> website >>> during query time? > >
