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.
