Open iamtomcheng opened 6 years ago
You probably don't want to be filtering on the date client side, rather use the server side filtering. For example to get the games for iamtomcheng on new years day use a url something like this:
https://api.halite.io/v1/api/user/4882/match?limit=250&filter=time_played,>=,2018-01-01T00:00&filter=time_played,<,2017-01-02T00:00
You'll still generally need to make multiple requests with appropriate limit and offsets to get the complete day.
Also if you do want to do any date filtering on the client side it'd probably be best to use the time_played
field returned with the metadata rather than parsing it out of the replay name.
@Janzert So I tried your url and it seems like the second server side filter on time_played
is not working, i.e. 250 replays starting from 2018-01-01T00:00
are returned, and also you put 2017
instead of 2018
. I removed the second filter on time_played
, add the offset back and add a client side filter using the time_played
field to keep the logic simple.
Sorry, so besides the obvious date typo it seems like when multiple filters of the same type are applied they get combined as first_filter OR second_filter
. So the above query ends up matching for every game.
Filters of different types (e.g. game_id and time_played) do get applied with AND, so I have no idea what is going on.
And yes no matter what any single query will only return a maximum of 250 games, that's what I meant about needing to use multiple requests with appropriate limit and offsets.
Hi @j-clap, could you take a look at the modifications and see if there is still any other issue? Thanks.
Hi @harikmenon, could you take a look at the changes made and see if it is okay now. Also, as pointed out by @Janzert, there is a bug (?) in the Halite API that when multiple filters of the same type are applied they get combined as first_filter OR second_filter
instead of first_filter AND second_filter
. Maybe you would like to fix that as well if it was not intentional.
@j-clap can you review?
To be clear the OR'ing of multiple uses of a filter in the api is definitely intentional. I'm not sure when the capability is used, but it is special cased in the code to make it OR instead of AND. Certainly both are useful in different situations.
This is a quick fix by adding the date as argument in the respective methods and classes and adding an if statement to skip replays that belong to the wrong date in case the requested date is given as input. Please feel free to amend it to make it more efficient.