fix: created_at ordering for file listings#3437
Conversation
|
|
|
Let's wait for further discussion to see if this is by design or a missing piece. |
|
修复后 |
Thanks for the clarification. I agree that for normally uploaded files, "created_at" and auto-incrementing "id" should usually be equivalent. I noticed this while writing a tool to index external files without copying them. The tool writes records directly and syncs filesystem timestamps into the database, so "created_at" may differ from insertion order. In that case, falling back to "id" ordering gives unexpected results. So this likely does not affect normal uploads, but matters for external indexing/import workflows. |
|
Good catch! I feeels we need to add a new index for (file_children, type, created_at), but let me address this in a seperate commit. |
Summary
This PR fixes file listing order when
order_by=created_atis requested.Previously,
created_atwas not mapped to the actual file order options, so both offset and cursor pagination could fall back to ID ordering instead of sorting bycreated_at. This change adds propercreated_atsorting, fixes the cursor predicate forcreated_at, and includescreated_atin the next-page token so pagination remains stable across pages.Testing
created_atsorting in offset paginationcreated_atcursor paginationAffected APIs
This change affects the file listing API:
GET /api/v4/fileThe fix applies when using query parameters such as:
uripagepage_sizeorder_by=created_atorder_direction=asc|descnext_page_tokenIn particular, it fixes:
order_by=created_atis requestedcreated_atsorting across pages