Thank you for your answer.
Do you mean I should index the availability data as a document in Solr?
Because the availability data in our databases is around 6,509,972 records
and contains the availability per number of seats and per 15 minutes. I also
tried this method, and as far as I know it's only possible to join the
availability documents and not to include that information per result
document.
An example API response (created from the Solr response):
{
restaurants: [
{
id: 13906,
name: Allerlei,
zipcode: 6511DP,
house_number: 59,
available: true
},
{
id: 13907,
name: Voorbeeld,
zipcode: 6512DP,
house_number: 39,
available: false
}
],
resultCount: 12156,
resultCountAvailable: 55,
}
I'm currently hacking around the problem by executing the search again with
a very high value for the rows parameter and counting the number of
available restaurants on the backend, but this causes a big performance
impact (as expected).
--
View this message in context:
http://lucene.472066.n3.nabble.com/Restaurant-availability-from-database-tp4065609p4065710.html
Sent from the Solr - User mailing list archive at Nabble.com.