Skip to content

Conversation

@sanghoon9173
Copy link

Should we return success with endOfPaginationReached set to true if nextKey is null for Append LoadType?

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@sanghoon9173
Copy link
Author

@googlebot I signed it!

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@sanghoon9173
Copy link
Author

Also, one question:
Let's say we cached everything from remote (nextKey for the last item in the last page is null). At this point there is more repos added to the server. However, the client thinks that it has already fetched everything, and therefore it won't try get the newly added repos. How would we handle this case?

@dlam
Copy link
Collaborator

dlam commented Jul 21, 2020

We should never get into this situation when fetching the remote nextKey from DB as the page that would've written null for nextKey in RemoteKey DB already returns endOfPaginationReached = true for MediatorResult, so we never expect to get another APPEND load in RemoteMediator after that.

Also, one question:
Let's say we cached everything from remote (nextKey for the last item in the last page is null). At this point there is more repos added to the server. However, the client thinks that it has already fetched everything, and therefore it won't try get the newly added repos. How would we handle this case?

If you have an external signal for data staleness or new data, you can simply insert the new data into DB and let PagingSource invalidation propagate REFRESH for you. In case the logic for receiving / fetching those items is the same as RemoteMediator implementation and you want to avoid duplicating logic already in RemoteMediator, you can also just call adapter.refresh() manually.

@florina-muntenescu florina-muntenescu force-pushed the step13-19_network_and_database branch from 8a5b401 to a2ff45c Compare July 23, 2020 19:02
@florina-muntenescu florina-muntenescu force-pushed the step13-19_network_and_database branch 2 times, most recently from fbf8ed3 to a42d4a1 Compare November 2, 2020 18:44
@florina-muntenescu florina-muntenescu force-pushed the step13-19_network_and_database branch from a42d4a1 to a7498e8 Compare November 18, 2020 17:26
@florina-muntenescu florina-muntenescu force-pushed the step13-19_network_and_database branch from a7498e8 to cf1c73b Compare January 6, 2021 10:55
@florina-muntenescu florina-muntenescu force-pushed the step13-19_network_and_database branch 4 times, most recently from 86491ee to 5f1732e Compare March 22, 2021 18:14
@florina-muntenescu
Copy link
Collaborator

Logic here was changed meanwhile

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants