Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undetermined maximum number of guests #287

Open
rmascarenhas opened this issue Aug 27, 2016 · 12 comments
Open

Undetermined maximum number of guests #287

rmascarenhas opened this issue Aug 27, 2016 · 12 comments

Comments

@rmascarenhas
Copy link
Contributor

Description

When publishing a property, one of the required fields is the maximum number of guests the property supports. SAW provides such information using an endpoint to quote prices. However, when the (arbitrarily selected) dates are not available, the information is not returned, even though they confirmed the data does not change over time.

Possible solutions

We need to ask them if there is any way to get the maximum guests information without having to make a call with arbitrary dates, otherwise we will our success in getting that information will depend solely on sheer luck.

Occurrences

#307467, #307466, #307465

@leandrocg
Copy link

I guess they already confirmed there is no other way.

As a creative solution, could we try again for few more times with different arbitrarily selected dates?

@rmascarenhas
Copy link
Contributor Author

That could work. But perhaps what could be more efficient would be for us to try to quote the price 1 year from now, as opposed to 1 month from now, as we are currently doing. The chances of the unit to be booked in a month's time are way higher than in a year's time.

What do you reckon, @sharipov-ru, @leandrocg? We could experiment with that.

@rmascarenhas
Copy link
Contributor Author

Since they already mentioned that adding the field in PropertyDetails is not possible, I'm removing the contact-support tag from this issue.

@leandrocg
Copy link

leandrocg commented Sep 8, 2016

Looks like a clever suggestion 👍

@sharipov-ru
Copy link
Contributor

But perhaps what could be more efficient would be for us to try to quote the price 1 year from now, as opposed to 1 month from now, as we are currently doing. The chances of the unit to be booked in a month's time are way higher than in a year's time.

I did quick testing on a few properties and was able to find couple properties which start return prices in far future (not 1 year from now, but 3-5 months from now).

I'll come back with numbers of how many properties can get better results after better testing that.

@rmascarenhas
Copy link
Contributor Author

rmascarenhas commented Sep 14, 2016

I would still test with dates further than 5 months from now. I remember Maria mentioning in our call to make a test booking one year from now, so it's possible their API do return availabilities for dates that far.

@rmascarenhas
Copy link
Contributor Author

If anything, we can test both 5 months and 1 year and compare.

@sharipov-ru
Copy link
Contributor

When I tested bookings with one year from now I got "Rates are not available for this property", I'll test full inventory with different date ranges and let you know about numbers/stats

@rmascarenhas
Copy link
Contributor Author

Ah, I see, thanks! 👍

@sharipov-ru
Copy link
Contributor

@rmascarenhas @leandrocg some stats from production.

Overall number of properties: 334

fetching prices for a 1 day stay after 1 month from now:

Number of properties with unit prices: 256

fetching prices for a 1 day stay after 3 month from now:

Number of properties with unit prices: 267

fetching prices for a 1 day stay after 6 month from now:

Number of properties with unit prices: 238

Also, there is small difference when fetching properties for different numbers of days, so when fetching prices for stay length of 2 days, API return bit more properties:

fetching prices for a 1 day stay after 1 month from now:

Number of properties with unit prices: 265

fetching prices for a 1 day stay after 3 month from now:

Number of properties with unit prices: 288

fetching prices for a 1 day stay after 6 month from now:

Number of properties with unit prices: 254

@sharipov-ru
Copy link
Contributor

I did test sync from SAW production yesterday.

We currently have:

~35 invalid postal code properties
~25 wrong destination id properites
~35-40 propeties without max_guests or 0.0 prices for units

In #289 I mentioned that for 334 properties from production only 11 don't have property prices set (which doesn't mean that they all are valid: postal codes, destination_ids and max_guests can still be wrong). Overall, I got almost 100 invalid properties by different reasons.

One common case when property is invalid is when one of its units are invalid (price fetching failed due "on request" property and even when I'm copying prices for units from property in that case, I still can't find max_guests estimation and unit is considered as invalid).

Moreover, there is an interesting scenario while sync:

Sync N1.

Property with ID = 555 has units with ID = 1, ID=2, ID=3, ID=4
Let's say that unit with ID=1 is on request and have no rates and max_guests. Then unit (and property) are not valid.

Sync N2.

Something has changed and now unit with ID=1 is valid returning prices and max_guests. But unit with ID=2 become not-valid and now we can't fetch its prices and max_guests. Then property is still not valid.

So without having a special cache, where we can access old prices / max_guest values, we can end up in problem when properties with multiple units inside are always not valid because of the units inside.

Probably we can remove invalid units from property while sync, probably we can create a cache storing historical prices / max_guests values for units, let me know what thoughts do you guys @rmascarenhas @leandrocg have on this?

@keang keang added the wontfix label Nov 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants