Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los cursores de consulta permiten que una aplicación recupere los resultados de una consulta en lotes prácticos, y se recomienda usarlos en lugar de desplazamientos de números enteros para la paginación.
Si deseas obtener más información sobre la estructuración de consultas para tu app, revisa Consultas.
Cursores de consulta
Los cursores de consulta permiten que una aplicación recupere los resultados de una consulta en lotes prácticos sin la sobrecarga de un desplazamiento de consulta. Después de realizar una operación de recuperación, la aplicación puede obtener un cursor, que es una string opaca codificada en base64 que marca la posición en el índice del último resultado recuperado. La aplicación puede guardar esta string, por ejemplo, en Datastore, en Memcache, en una carga útil de tareas de la lista de tareas en cola o incorporada en una página web como un parámetro HTTP GET o POST y, luego, usar el cursor como punto de partida para una operación de recuperación posterior a fin de obtener el siguiente lote de resultados desde el punto en que finalizó la recuperación anterior. En una recuperación, también se puede especificar un cursor de fin para limitar la extensión del conjunto de resultados mostrado.
Desplazamientos frente a cursores
Si bien Datastore admite desplazamientos de números enteros, no es recomendable usarlos. En su lugar, usa cursores. Usar un desplazamiento solo evita que se muestren las entidades omitidas en la aplicación, pero se siguen recuperando internamente. Las entidades omitidas afectan a la latencia de la consulta y tu aplicación se factura por las operaciones de lectura necesarias para recuperarlas. Usar cursores en lugar de desplazamientos te permite evitar todos estos costos.
Ejemplo de cursor de consulta
En Python, una aplicación obtiene un cursor después de recuperar resultados de consultas mediante una llamada al método cursor() del objeto Query. Para recuperar resultados adicionales desde el punto del cursor, la aplicación prepara una consulta similar con los mismos filtros, órdenes de clasificación y tipo de entidad, y pasa el cursor al método with_cursor() de la consulta antes de realizar la recuperación:
fromgoogle.appengine.apiimportmemcachefromgoogle.appengine.extimportdb# class Person(db.Model): ...# Start a query for all Person entitiespeople=Person.all()# If the application stored a cursor during a previous request, use itperson_cursor=memcache.get('person_cursor')ifperson_cursor:people.with_cursor(start_cursor=person_cursor)# Iterate over the resultsforpersoninpeople:# Do something# Get updated cursor and store it for next timeperson_cursor=people.cursor()memcache.set('person_cursor',person_cursor)
Limitaciones de los cursores
Los cursores están sujetos a las siguientes limitaciones:
Un cursor solo puede usarse en la misma aplicación que realizó la consulta original y solo para continuar la misma consulta. Para usar el cursor en una operación de recuperación posterior, debes reconstituir la consulta original exactamente, incluidos el mismo de tipo de entidad, filtro de principal, filtros de propiedades y órdenes de clasificación. No es posible recuperar resultados mediante un cursor sin configurar la misma consulta desde la que se generó.
Debido a que los operadores != y IN se implementan con varias consultas, aquellas que los usan no admiten cursores.
Los cursores no siempre se comportan de la forma esperada con una consulta que usa un filtro de desigualdad o un orden de clasificación en una propiedad con varios valores. La lógica de deduplicación para esas propiedades con varios valores no persiste entre las recuperaciones, lo que, posiblemente, hará que el mismo resultado se muestre más de una vez.
Las versiones nuevas de App Engine podrían cambiar los detalles de la implementación interna, lo que invalida los cursores que dependen de ellos. Si una aplicación intenta usar un cursor que ya no es válido, Datastore genera una excepción BadRequestError.
Actualizaciones de datos y cursores
La posición del cursor se define como la ubicación en la lista de resultados que sigue al último resultado que se mostró. Un cursor no es una posición relativa en la lista (no es un desplazamiento), es un marcador al que puede saltar Datastore cuando se inicia un análisis de índice para obtener resultados. Si los resultados de una consulta cambian entre los usos de un cursor, la consulta notará solo los cambios que se producen en los resultados que aparecen después del cursor. Si aparece un resultado nuevo antes de la posición del cursor para la consulta, este no se mostrará cuando se recuperen los resultados que aparecen después del cursor.
De igual modo, si una entidad ya no es un resultado para una consulta, pero ha aparecido antes del cursor, los resultados que aparecen después del cursor no se modifican. Si se quita el último resultado que se muestra del conjunto de resultados, el cursor aún podrá localizar el resultado siguiente.
Cuando se recuperan resultados de consulta, puedes usar un cursor de inicio y un cursor de fin para que se muestre un grupo continuo de resultados de Datastore. Cuando se usa un cursor de inicio y de fin para recuperar los resultados, no hay garantía de que el tamaño de los resultados será el mismo que cuando se generaron los cursores.
Se pueden agregar o borrar entidades de Datastore desde que se generan los cursores hasta antes de que se los use en una consulta.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eQuery cursors allow applications to retrieve query results in batches, marking the position of the last retrieved result as an opaque, base64-encoded string.\u003c/p\u003e\n"],["\u003cp\u003eUsing cursors instead of integer offsets is recommended because offsets still retrieve skipped entities internally, affecting latency and incurring read operation costs.\u003c/p\u003e\n"],["\u003cp\u003eCursors can be saved and used later to continue a query from where it left off, allowing applications to get the next batch of results.\u003c/p\u003e\n"],["\u003cp\u003eCursors have limitations, such as only being usable by the same application for the same query and not supporting \u003ccode\u003e!=\u003c/code\u003e and \u003ccode\u003eIN\u003c/code\u003e operators.\u003c/p\u003e\n"],["\u003cp\u003eThe position of a cursor is defined as the location after the last returned result, and while it is not affected by results that come before the cursor, new additions or removals after the cursor can impact results.\u003c/p\u003e\n"]]],[],null,["# Query Cursors\n\n*Query cursors* allow an application to retrieve a query's results in convenient\nbatches, and are recommended over using integer offsets for pagination.\nSee [Queries](/appengine/docs/legacy/standard/python/datastore/queries) for more information on structuring queries for your app.\n\nQuery cursors\n-------------\n\n*Query cursors* allow an application to retrieve a query's results in convenient\nbatches without incurring the overhead of a query offset. After performing a\n[retrieval operation](/appengine/docs/legacy/standard/python/datastore/retrieving-query-results), the application can obtain a\ncursor, which is an opaque base64-encoded string marking the index position of\nthe last result retrieved. The application can save this string, for example in\nDatastore, in Memcache, in a Task Queue task payload, or embedded in\na web page as an HTTP `GET` or `POST` parameter, and can then use the cursor as\nthe starting point for a subsequent retrieval operation to obtain the next batch\nof results from the point where the previous retrieval ended. A retrieval can\nalso specify an end cursor, to limit the extent of the result set returned.\n\nOffsets versus cursors\n----------------------\n\nAlthough Datastore supports integer offsets, you should avoid\nusing them. Instead, use cursors. Using an offset only avoids returning the\nskipped entities to your application, but these entities are still retrieved\ninternally. The skipped entities do affect the latency of the query, and your\napplication is billed for the read operations required to retrieve them. Using\ncursors instead of offsets lets you avoid all these costs.\n\nQuery cursor example\n--------------------\n\nIn Python, an application obtains a cursor after retrieving query results by\ncalling the `Query` object's [`cursor()`](/appengine/docs/legacy/standard/python/datastore/queryclass#Query_cursor) method. To\nretrieve additional results from the point of the cursor, the application\nprepares a similar query with the same entity kind, filters, and sort orders,\nand passes the cursor to the query's\n[`with_cursor()`](/appengine/docs/legacy/standard/python/datastore/queryclass#Query_with_cursor) method before performing the\nretrieval: \n\n from google.appengine.api import memcache\n from google.appengine.ext import db\n\n # class Person(db.Model): ...\n \n # Start a query for all Person entities\n people = Person.all()\n \n # If the application stored a cursor during a previous request, use it\n person_cursor = memcache.get('person_cursor')\n if person_cursor:\n people.with_cursor(start_cursor=person_cursor)\n \n # Iterate over the results\n for person in people:\n # Do something\n \n # Get updated cursor and store it for next time\n person_cursor = people.cursor()\n memcache.set('person_cursor', person_cursor)\n\n| **Note:** Because of the way the iterator interface retrieves results in batches, getting a cursor may result in an additional call to Datastore to position the cursor where the iterator left off. If using only a start cursor, and if you know how many results you need ahead of time, it's faster to use [`fetch()`](/appengine/docs/legacy/standard/python/datastore/queryclass#Query_fetch).\n| **Caution:** Be careful when passing a Datastore cursor to a client, such as in a web form. Although the client cannot change the cursor value to access results outside of the original query, it is possible for it to decode the cursor to expose information about result entities, such as the application ID, entity kind, key name or numeric ID, ancestor keys, and properties used in the query's filters and sort orders. If you don't want users to have access to that information, you can encrypt the cursor, or store it and provide the user with an opaque key.\n\n### Limitations of cursors\n\nCursors are subject to the following limitations:\n\n- A cursor can be used only by the same application that performed the original query, and only to continue the same query. To use the cursor in a subsequent retrieval operation, you must reconstitute the original query exactly, including the same entity kind, ancestor filter, property filters, and sort orders. It is not possible to retrieve results using a cursor without setting up the same query from which it was originally generated.\n- Because the `!=` and `IN` operators are implemented with multiple queries, queries that use them do not support cursors.\n- Cursors don't always work as expected with a query that uses an inequality filter or a sort order on a property with multiple values. The de-duplication logic for such multiple-valued properties does not persist between retrievals, possibly causing the same result to be returned more than once.\n- New App Engine releases might change internal implementation details, invalidating cursors that depend on them. If an application attempts to use a cursor that is no longer valid, Datastore raises a [`BadRequestError`](/appengine/docs/legacy/standard/python/datastore/exceptions#BadRequestError) exception.\n\n### Cursors and data updates\n\nThe cursor's position is defined as the location in the result list after the\nlast result returned. A cursor is not a relative position in the list\n(it's not an offset); it's a marker to which Datastore can jump\nwhen starting an index scan for results. If the results for a query change\nbetween uses of a cursor, the query notices only changes that occur in results\nafter the cursor. If a new result appears before the cursor's position for the\nquery, it will not be returned when the results after the cursor are fetched.\nSimilarly, if an entity is no longer a result for a query but had appeared\nbefore the cursor, the results that appear after the cursor do not change. If\nthe last result returned is removed from the result set, the cursor still knows\nhow to locate the next result.\n\nWhen retrieving query results, you can use both a start cursor and an end cursor\nto return a continuous group of results from Datastore. When\nusing a start and end cursor to retrieve the results, you are not guaranteed\nthat the size of the results will be the same as when you generated the cursors.\nEntities may be added or deleted from Datastore between the\ntime the cursors are generated and when they are used in a query.\n\nWhat's next?\n------------\n\n- [Learn how to specify what a query returns and further control query\n results](/appengine/docs/legacy/standard/python/datastore/retrieving-query-results).\n- Learn the [common restrictions](/appengine/docs/legacy/standard/python/datastore/query-restrictions) for queries on Datastore.\n- [Understand data consistency](/appengine/docs/legacy/standard/python/datastore/data-consistency) and how data consistency works with different types of queries on Datastore.\n- Learn the [basic syntax and structure of queries](/appengine/docs/legacy/standard/python/datastore/queries) for Datastore."]]