cursorPaginate に変えると、できなくなることは何ですか。
ページ番号での移動と、総件数・総ページ数の表示です。公式も「Next と Previous のリンクしか作れない」と明記しています。並び順に一意なキーを含める制約も付きます。
面接官が見ているのは置き換えの代償まで見えているか。
これは「一覧APIで paginate() を使ったら重くなりました。なぜですか。どうしますか。」への追撃質問です。
よくある答えと、面談でどう見られるか
- ページ番号での移動と総件数の表示ができなくなる。ソート列に一意性も必要になる
その通りです。null を含む列も使えません。作成日時だけでソートすると同時刻のレコードで取りこぼしが起きるので、ID を第2キーに加えます。 - 特に失うものはない
ページ番号による移動ができなくなります。UI の作りに直結します。 - ソートができなくなる
ソートはできます。ただし基準列に一意性が要ります。 - 件数の多いテーブルでは使えない
逆です。件数が多いほど有利な方式です。
面接官は何を見ているか
- 「3ページ目に飛ぶ」ようなページ番号指定ができないと指摘できた
- 総件数・総ページ数が出せないと指摘できた
- ソート順に一意なキーが必要だと言えた
模範解答
失うのは2つ。ページ番号での移動と、総件数・総ページ数の表示です。公式ドキュメントの記載では「cursor pagination は Next / Previous のリンクしか作れず、ページ番号付きのリンク生成には対応しない」。CursorPaginator には total() 自体がありません。
制約もあります。ソートの基準が「少なくとも1つの一意な列、または一意になる列の組み合わせ」である必要があり、null を含む列は使えません。作成日時だけでソートすると同時刻のレコードで取りこぼしや重複が起きるので、ID を第2キーに加えます。
逆に、書き込みが多いデータでは OFFSET 方式のほうが取りこぼしや重複を起こします（見ている間に行が増減すると位置がずれるため）。無限スクロールとは相性が良く、ページ番号付きの一覧とは相性が悪い、という整理になります。