Filtering based on date availability

Hi all,

Imagine the scenario where products are “booked” for certain dates - like at a rental company.

I want the user to be able to enter in preferred rental dates (e.g. 24-Feb-17 to 28-Feb-17) and Algolia to only return products that are not booked on any of those dates.

Regularly uploading a list of dates that each product is booked to Algolia should be no problem.

I’ve had a bit of a play with the filters and operators using the Explorer, but can’t get the outcome I desire. For the moment I’m just trying it with simple numerical data, rather than dates.

Any thoughts on whether this functionality would be possible, and if so, how one might go about it?

Cheers
Baz

Bump. No ideas on how to handle this?

Sorry about not getting a response yet, we’re still learning the ropes of Discourse and this one honestly fell through the cracks. I pinged our dev team to see if they can help here.

Availability is tricky but I know we have people doing just this, whether it’s via filters or indexing multiple records, one per item per availability slot.

I would be interested as I came to see if anyone else is doing something like this as well. We’re trying to grok how we can store business hours for business’ and have them be filterable based on time/date data(open & closed).

1 Like

@dzello - how did you go with the dev team?

Here is one way that we recommend to do it.

The general idea is to create one record per consecutive block of availability:

To query, you then use numeric filter that reflect the range the user is looking for.

Thanks for that.

Your solution got me thinking… I think a better way to do it might be like so:

{
“product”: “Product 1”,
“availability”: [1,2,3,4,12,13,14,15,16,17,18,19,20,21,25,26,27,28,29,30]
}

Then for a 3 day hire, pass filters:

availability = 2
availability = 3
availability = 4

Returns Product 1.

availability = 3
availability = 4
availability = 5

Does not return Product 1

Seems to work for the very basic example I just set up.

What do you think about this approach? More availability values passed through as you can’t use ranges, but at least you don’t need more than 1 record per product. Something about doing that makes me uneasy. You couldn’t use a common object ID between the 2 records even though they are the same product. It also significantly increases your record count which can affect your costs based on Algolia’s pricing plans.

That looks like it’ll work too, and like you said it cuts down on the number of records.

The only thing to watch out for is potential performance degradation if you pass more than ~15 filters against a large dataset (millions of records). Some basic performance testing along the way will help you spot any issues. This might not be a big issue if the user generally searches over a small window of dates.

Cheers. I don’t see myself ever having more than 10-20K records (currently only 2.4K and won’t grow very quickly). Availability will be limited to the following 3 months.

So currently there would be up to 216,000 availability values (2.4K * 90 days).

At most, there will be 1.8m availability values. This is a long way off though and by then there might be different ways of handling this problem.

1 Like

You should be good then. Keep us posted about how it goes as you move forward :slight_smile: