Closed omz1990 closed 1 year ago
Hi @isFakeAccount. Any thoughts on this?
if the user sends a limit of 200 from the client side, it will only return 200 games, and there is currently no way to paginate to further results.
Yes? Why would you paginate further when there isn't any data that needs to be fetched? If you want more items, you can increase the limit to a bigger value. The method will take care of pagination and return the data.
In the future even if a similar scenario happens, the clients can reduce the limit even further and will still be able to access the remaining data by providing an offset.
This makes sense, Like instead of having limit_per_page = min(limit, 500) if limit is not None else 500
, this should be passed as default args. This will allow users to change the page size if Sony decides to change the endpoint properties.
But I don't see you have made these changes. You set it to 200, which will become an issue again if Sony decides to change the max page size to 100 or even lower.
If you want more items, you can increase the limit to a bigger value. The method will take care of pagination and return the data.
But I don't see you have made these changes.
Adding an offset
allows clients to implement an efficient lazy loading functionality. As an example my apps load 200 trophy titles and title stats per page, it doesn't make sense for me to load the entire data if its not needed. In the current state the clients need to always fetch all of the data, for larger profiles that takes a lot of time and wasted memory. Yes, in the case no limit is provided the library method will paginate and return all results, but adding limit
and offset
enables the clients to paginate more flexibly.
Given now the limit has been decreased to 200 by Sony, with larger profiles with 8000+ games, the library function may need to paginate 40/50+ times which in itself has the potential to timeout to fetch all the data.
Adding an offset allows clients to implement an efficient lazy loading functionality. As an example my apps load 200 trophy titles and title stats per page, it doesn't make sense for me to load the entire data if its not needed.
What app are you making? Is it a web/mobile app? Then it makes sense. Most of the time people want to search for "X" title game, to do that they have to iterate anyways.
What app are you making? Is it a web/mobile app?
Yes, I’m making mobile apps with a dedicated backend which is using this library. To ensure the responses are fast I only load the data I need when I need it. This way I’m easily able to do it.
Hi @isFakeAccount. Want to follow up on this and see if you're considering adding this? Thanks.
I have a better way of doing this. It will allow you to skip items with higher flexibility. Something like this.
# First 10 title stats
title_stat_iterator = user_example.title_stats(limit=10, page_size=10)
first_ten = list(title_stat_iterator)
# 30-40th title stat
title_stat_iterator.title_stats_paginator.set_offset(29)
thirtieth_40th_stats = list(title_stat_iterator)
Hi @isFakeAccount. Just saw the recent releases. Your solution for title stats pagination looks pretty neat. Thanks I'll close this PR and keep an eye out for when you do the same for trophy titles.
title_stats
limit from 500 to 200. (addresses https://github.com/isFakeAccount/psnawp/issues/43 and https://github.com/isFakeAccount/psnawp/issues/45)offset
totrophy_titles
andtitle_stats
to enable pagination.Issue: Without an
offset
, in the current scenario of the limit being decreased from 500 to 200 in title_stats, if the user sends a limit of 200 from the client side, it will only return 200 games and there is currently no way to paginate to further results. In the future even if a similar scenario happens, the clients can reduce the limit even further and will still be able to access the remaining data by providing an offset. I have added the same fortrophy_titles
as that too requires pagination for large profiles and may be hit with a similar limit in the future.