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

feat(page): add page param to support pagination without knowing dids #254

Merged
merged 7 commits into from
Dec 2, 2019

Conversation

Avantol13
Copy link
Contributor

New Features

  • add page param to list records endpoint to support pagination without using a did

Breaking Changes

Bug Fixes

Improvements

Dependency updates

Deployment changes

@github-actions
Copy link

The style in this PR agrees with black. ✔️

This formatting comment was generated automatically by a script in uc-cdis/wool.

@lgtm-com
Copy link

lgtm-com bot commented Nov 24, 2019

This pull request introduces 1 alert and fixes 2 when merging fec1b25 into 2d43b97 - view on LGTM.com

new alerts:

  • 1 for Syntax error

fixed alerts:

  • 2 for Unused import

Copy link
Contributor

@paulineribeyre paulineribeyre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good but i think we need some unit tests with just page and with both page and limit

Comment on lines 443 to 445
query = query.order_by(IndexRecord.updated_date)
else:
query = query.order_by(IndexRecord.did)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we just always order by date?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that... probably? I was afraid to change the existing behavior tbh, but I guess it shouldn't matter, you'll always get the next did regardless of the ordering

# (e.g. parallelly processing from beginning -> middle and ending -> middle
# and as a final step, checking the "ending"+1 to see if there are
# new records).
query = query.order_by(IndexRecord.updated_date)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not order by decreasing date? if we use this to validate after indexing for example, we could just get the first pages

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this is set the dates later in the past will be first such that any additional records end up at the end. This means that existing pages won't change content, whereas if we were to do the opposite, a new record would bump everything else forward, changing the content on all existing pages. So I didn't want to break things mid-processing. If you're curious, this is the logic I was cross-testing with gen3 sdk: https://github.com/uc-cdis/gen3sdk-python/blob/907d418ebcf46ea345472229982c604c54cce179/gen3/tools/indexing.py#L82

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense!! thanks

@Avantol13 Avantol13 merged commit d3c3d3e into master Dec 2, 2019
@Avantol13 Avantol13 deleted the feat/pagination branch December 2, 2019 18:16
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.

None yet

2 participants