How to use pydantic model on UseAdditionalFields ?

[Kavan72]

Discussed in #1451

^{Originally posted by Kavan72 January 29, 2025}
I've my pydantic model and i want to use on UseAdditionalFields, like this

CustomPage = CustomizedPage[
    Page[T],
    UseAdditionalFields(
        extra=MyCustomModel
    ),
]

My code for custom page

from collections.abc import Sequence
from math import ceil
from typing import Any, TypeVar

from fastapi_pagination import paginate
from fastapi_pagination.bases import AbstractParams, BasePage, RawParams
from pydantic import BaseModel, Field

T = TypeVar("T")


class CustomParams(BaseModel, AbstractParams):
    page: int = Field(1, ge=1, description="Page number")
    page_size: int = Field(10, ge=1, le=1000, alias="pageSize", description="Page size")

    def to_raw_params(self) -> RawParams:
        return RawParams(
            limit=self.page_size if self.page_size is not None else None,
            offset=self.page_size * (self.page - 1)
            if self.page is not None and self.page_size is not None
            else None,
        )

    @classmethod
    def get_alias(cls, field_name: str):
        field = cls.__pydantic_fields__.get(field_name)

        if field is None:
            raise AttributeError(f"Field {field_name} is not defined")

        return field.alias or field_name


class CustomPage(BasePage):
    __qualname__ = "Page"

    page: int = Field(strict=True, ge=1, alias=CustomParams.get_alias("page"))
    page_size: int = Field(strict=True, ge=1, alias=CustomParams.get_alias("page_size"))
    pages: int = Field(strict=True, ge=0)

    @classmethod
    def create(
        cls,
        items: Sequence[T],
        params: CustomParams,
        *,
        total: int | None = None,
        **kwargs: Any,
    ):
        page_size = params.page_size if params.page_size is not None else (total or None)
        page = params.page if params.page is not None else 1

        if page_size in {0, None}:
            pages = 0
        elif total is not None:
            pages = ceil(total / page_size)
        else:
            pages = None

        return cls.model_validate(
            {
                "total": total,
                "items": items,
                "page": page,
                "page_size": page_size,
                "pages": pages,
                **kwargs,
            },
            from_attributes=True,
        )

class UserCount(BaseModel):
    active: int
    invited: int
    banned: int
    rejected: int

class Custom(CustomPage):
    __qualname__ = "Page"
    extra: UserCount

@app.get("/nums")
async def get_nums(is_admin: bool = False) -> Custom[int]:
    return paginate(
        range(1_000),
        params=CustomParams(page=1, page_size=10),
        additional_data={
            "extra": UserCount(active=1, banned=2, rejected=3, invited=4),
        }
    )

Since I’m not using add_pagination(app), FastAPI Pagination can’t find my custom page class. Is there any way to pass the class into the paginate method so it can use my custom page? Sorry, but I don’t prefer using add_pagination or set_page.

[Kavan72]

@uriyyo, any suggestions? I’m happy to contribute to this.

[uriyyo]

Sorry, but I don’t prefer using add_pagination or set_page.

@Kavan72 But it's kinda required to use, otherwise you will use default Page class.

Is there any reason why you don't want to use add_pagination or set_page?

There is also pagination_ctx function, you can take a look at it here - https://uriyyo-fastapi-pagination.netlify.app/learn/tutorial_advanced/low_level_api/#pagination_ctx

[Kavan72]

Sorry, but I don’t prefer using add_pagination or set_page.

@Kavan72 But it's kinda required to use, otherwise you will use default Page class.

Is there any reason why you don't want to use add_pagination or set_page?

There is also pagination_ctx function, you can take a look at it here - https://uriyyo-fastapi-pagination.netlify.app/learn/tutorial_advanced/low_level_api/#pagination_ctx

Actually, I don’t like monkey patching, which is why I’m avoiding this. I also have my own OpenAPI build function, and I don’t want any library modifying my OpenAPI schema. While pagination_ctx is fine, it’s not an ideal solution. You mentioned that I’m Depends on this, but that’s not accurate. A custom page is a response class, not something that relies on a dependency.

[uriyyo]

You mentioned that I’m Depends on this, but that’s not accurate. A custom page is a response class, not something that relies on a dependency.

Sorry, I guess my message was not clear.

When you call paginate function it depends on a value of contextvar that holds page class that should be used.
In order to use correct page class you need to set it, it can be done using set_page, pagination_ctx or add_pagination functions.

add_pagination does some monkey-patching but both set_page and pagination_ctx don't, they just change value of context-var.

You can see it here:

fastapi-pagination/fastapi_pagination/api.py

Lines 135 to 136 in f867c15

	def set_page(page: type[AbstractPage[Any]]) -> AbstractContextManager[None]:
	return _ctx_var_with_reset(_page_val, page)

[Kavan72]

You mentioned that I’m Depends on this, but that’s not accurate. A custom page is a response class, not something that relies on a dependency.

Sorry, I guess my message was not clear.

When you call paginate function it depends on a value of contextvar that holds page class that should be used. In order to use correct page class you need to set it, it can be done using set_page, pagination_ctx or add_pagination functions.

add_pagination does some monkey-patching but both set_page and pagination_ctx don't, they just change value of context-var.

You can see it here:

fastapi-pagination/fastapi_pagination/api.py

Lines 135 to 136 in f867c15

def set_page(page: type[AbstractPage[Any]]) -> AbstractContextManager[None]:
return _ctx_var_with_reset(_page_val, page)

Hey @uriyyo,

I understand what you’re trying to say. My idea is that if someone comes from a different framework or language, using pagination_ctx with Depends feels like a dirty solution. Honestly, I have no objections to your suggestion, and since you’re the owner of this library, you have full authority to decide what to do. My suggestion is to allow users to pass a CustomPage to the pagination function, which will use that class if provided; otherwise, it will fall back to the default. 🙂

[Kavan72]

@uriyyo hey any update 😅, if you are okay then I’m happy to contribute to this.

[uriyyo]

@Kavan72 Sorry for long response. I'm thinking about better solution how can we have feature as you suggested.

paginate function signature is already kinda overloaded with a lot of different required arguments.

I was thinking about smth like this:

from fastapi_pagination import paginate, LimitOffsetPage
from fastapi_pagination import pagination_for # new function

limit_offset_paginate = pagination_for(paginate, LimitOffsetPage)

What do you think about such API? Not sure if it's perfect.

Another option might be to introduce config parameter that might be extended in future:

from fastapi_pagination import paginate, LimitOffsetPage, Limit0ffsetParams, PaginationConfig

paginate(
     range(1_000),
     LimitOffsetParams(limit=100, offset=50),
     config=PaginationConfig(
          page=LimitOffsetPage,
     )
)

[Kavan72]

@Kavan72 Sorry for long response. I'm thinking about better solution how can we have feature as you suggested.

paginate function signature is already kinda overloaded with a lot of different required arguments.

I was thinking about smth like this:

from fastapi_pagination import paginate, LimitOffsetPage
from fastapi_pagination import pagination_for # new function

limit_offset_paginate = pagination_for(paginate, LimitOffsetPage)
What do you think about such API? Not sure if it's perfect.

Another option might be to introduce config parameter that might be extended in future:

from fastapi_pagination import paginate, LimitOffsetPage, Limit0ffsetParams, PaginationConfig

paginate(
range(1_000),
LimitOffsetParams(limit=100, offset=50),
config=PaginationConfig(
page=LimitOffsetPage,
)
)

Thanks for your response! I think introducing a config parameter is a better approach. It keeps the paginate function cleaner and allows for future extensions without making the function signature even more complex.

The first approach, while functional, adds more boilerplate code since every new pagination type would require wrapping with pagination_for.

The PaginationConfig method feels more flexible and scalable.

[uriyyo]

Thanks for feedback, than I will go with introducing config param.

[Kavan72]

Thanks for feedback, than I will go with introducing config param.

Welcome! 😊 BTW, if you need any help contributing, feel free to ping me here or on Discord (hidan411).