Feature/pagination

[BruceWW]

this is the feature that supports pagination,
with the param with_page_split as True, the method will calculate the length of result, split the result by page_num and page_size params and finally return previous url and next_url
pyandtic.BaseModel, sqlalchemy object and normal type are supported

[github-actions]

📝 Docs preview for commit 83f97b7 at: https://5f60859297653e8b289530e9--fastapi.netlify.app

[codecov]

Codecov Report

Merging #2056 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##            master     #2056    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          239       241     +2     
  Lines         7079      7249   +170     
==========================================
+ Hits          7079      7249   +170     

Impacted Files	Coverage Δ
fastapi/applications.py	100.00% <ø> (ø)
fastapi/pagination.py	100.00% <100.00%> (ø)
fastapi/routing.py	100.00% <100.00%> (ø)
tests/test_operations_signatures.py	100.00% <100.00%> (ø)
tests/test_response_with_page_split.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e77ea63...73ff0e9. Read the comment docs.

[github-actions]

📝 Docs preview for commit 988db14 at: https://5f60a1a2ffcb39009bbb4904--fastapi.netlify.app

[github-actions]

📝 Docs preview for commit 9033c5c at: https://5f60cc6a68e74a30a5d3e045--fastapi.netlify.app

[ycd]

I suggest you to use Typing's Dict and List for type-hinting since whole codebase based on Typing.

PR looks good overall 🎉 🚀

[BruceWW]

@ycd pertty agree with your suggestion, and it's been updated

[github-actions]

📝 Docs preview for commit 92737a1 at: https://5f61ad396d3cd4279f8e5c7d--fastapi.netlify.app

[Shark009]

Any idea when this will be merged and released?

[Kludex]

@Shark009 There's no confirmation that it will be merged...

[jrversteegh]

Despite its usefulness, this pagination option is not part of OpenAPI (as far as I am aware) and there are also competing options like page[number] and page[size] like used in json::api, so I don't think this should be in fastapi. Maybe in fastapi_utils or something?

[BruceWW]

Rest api do not suggest use json body while the request method is GET, so i think page[number] and page[size] is not a competitor. And fastapi_utils could be discussed

[github-actions]

📝 Docs preview for commit 73ff0e9 at: https://5f815194f2fb3ef5b5d431bd--fastapi.netlify.app

[tiangolo]

I see you did a lot of work here @BruceWW ! 🤓

Nevertheless, that would be a very tight/strict compromise in how FastAPI expects to be used. And I would prefer to not have it that way. That's the same reason why it is not tightly coupled with any specific ORM.

For example, you could imagine someone wanting to use an opaque "cursor" object instead of pages. Or someone querying a NoSQL DB like CouchDB with an index range based on dates, etc.

So I'm gonna pass on this. Nevertheless, if this is a feature that you, your team, and/or others are frequently needing, I encourage you to create an independent Python package that can be used with FastAPI.

And if you add the fastapi topic to the GitHub repo it will show up here: https://fastapi.tiangolo.com/external-links/#projects

Given that, I'm gonna pass on this. But thanks for your effort! 🍰 ☕

[jrversteegh]

@BruceWW page[number] and page[size] are not body parameters, but query parameters in json::api. See e.g. this discussion if you're interested: OAI/OpenAPI-Specification#1706