scan - Token a la página siguiente en API de paginación

dynamodb withkeyconditionexpression

Question

Tengo una lista de registros en el servidor ordenados por una clave y uso pagination API para devolver la lista de segmentos uno por uno. Como los elementos se pueden insertar en el medio de la lista, devuelvo la primera clave de la página siguiente como un token de paginación que debe pasarse para obtener la página siguiente.

Sin embargo, he encontrado que DynamoDB utiliza la última clave de la página actual para consultar API, que es nula si la página siguiente no existe.

Pregunta:

¿Cuáles son los pros y los contras entre usar el último elemento de la página actual y el primer elemento de la página siguiente como un token de paginación?

NÓTESE BIEN:

En cuanto a mí, devolver el primer artículo es más intuitivo ya que es nulo solo si la página siguiente no existe.

Answer 1

Usar el "último elemento de la página actual" ( LICP ) es mejor que usar el "primer elemento de la página siguiente" ( FINP ) porque trata mejor con la posibilidad de que, mientras tanto, se inserte algún elemento entre estos dos elementos .

Por ejemplo, supongamos que la primera página contiene 3 nombres ordenados alfabéticamente: Adam / Basil / Claude. Y supongamos que la siguiente página es Elon / Francis / Gilbert.

Luego, con LICP, el token es Claude , mientras que con FINP, el token es Elon . Si no se insertan nuevos nombres, el resultado será el mismo cuando obtengamos la página siguiente.

Sin embargo, supongamos que insertamos el nombre Daniel después de obtener la primera página pero antes de obtener la segunda página. En este caso, cuando tenemos la segunda página con LICP obtenemos a Daniel/Elon/Francis , mientras que con FINP obtenemos a Elon/Francis/Gilbert . Es decir, FINP extrañará a Daniel , mientras que LICP no lo hará.

Además, FINP puede consumir más recursos informáticos que LICP, ya que debe recuperar un elemento adicional (4 elementos, en el ejemplo anterior, en lugar de solo 3).