View a markdown version of this page

Pruebe el código de Gremlin en el contexto en el que lo va a implementar - Amazon Neptune

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Pruebe el código de Gremlin en el contexto en el que lo va a implementar

Gremlin proporciona múltiples formas para que los clientes envíen consultas al servidor. Estos modos de envío difieren en la forma en que se evalúan las consultas y en el comportamiento de las transacciones. Estas diferencias pueden generar resultados inesperados si se desarrolla en un modo y se implementa en otro.

Modo script (envío basado en cadenas)

En el modo script, el cliente envía la consulta completa como una cadena de texto al servidor. El servidor evalúa la cadena completa, incluidos los pasos del terminal, y envía los resultados al cliente. Las siguientes herramientas y métodos utilizan el modo de secuencia de comandos:

En el modo script, el cliente envía una consulta como la siguiente al servidor como una cadena completa:

// Script mode – the entire string, including .next(), is sent to the server
// V('non-existing-id') yields nothing because no vertex with that ID exists
Cluster cluster = Cluster.build().addContactPoint("your-neptune-endpoint")
                         .port(8182).enableSsl(true).create();
Client client = cluster.connect();
client.submit("g.V('existing-id').addV('person').V('non-existing-id').next()");

El servidor evalúa la consulta completa, incluida.next(). Si no .next() encuentra ningún resultado, el servidor genera un NoSuchElementException y la transacción se revierte.

Modo bytecode (objetos transversales GLV)

En el modo de código de bytes, el cliente crea un objeto transversal localmente mediante una variante del lenguaje Gremlin (GLV). El controlador serializa los pasos transversales como código de bytes y los envía al servidor. Los pasos terminales, como .toList() o, se .next() ejecutan en el lado del cliente para repetir los resultados devueltos por el servidor. Puede usar el modo de código de bytes con Java, Python, Go JavaScript, .NET y otros TinkerPop-compliant controladores de terceros adecuados para la versión del motor Neptune utilizada.

En el modo de código de bytes, la misma consulta tiene el siguiente aspecto:

// Bytecode mode – the driver sends the traversal steps as bytecode
// .next() executes on the client to iterate results
Cluster cluster = Cluster.build().addContactPoint("your-neptune-endpoint")
                         .port(8182).enableSsl(true).create();
GraphTraversalSource g = traversal().withRemote(
    DriverRemoteConnection.using(cluster));
g.V("existing-id").addV("person").V("non-existing-id").next();

El controlador envía solo los pasos transversales (g.V().addV().V()) como código de bytes. El servidor evalúa correctamente el recorrido, confirma la transacción y devuelve el conjunto de resultados. A continuación, el cliente llama .next() localmente para leer el conjunto de resultados. Si el conjunto de resultados está vacío, el cliente genera unNoSuchElementException, pero la transacción ya se ha confirmado en el servidor.

Diferencias de comportamiento en las transacciones

La diferencia fundamental entre estos modos es la forma en que los pasos terminales afectan a las transacciones:

  • Modo script: el servidor evalúa los pasos de la terminal. Si un paso final como este .next() falla porque el conjunto de resultados está vacío, el servidor considera que la consulta ha fallado y anula la transacción. El servidor no conserva ninguna mutación en el mismo recorrido (por ejemploaddV()).

  • Modo de código de bytes: el cliente evalúa los pasos del terminal. El servidor evalúa solo los pasos transversales, confirma correctamente la transacción y devuelve los resultados. Si, a continuación, el cliente invoca .next() un conjunto de resultados vacío, el resultado NoSuchElementException es solo un error del lado del cliente. La transacción ya se ha confirmado, por lo que el servidor conserva cualquier mutación.

Pasos terminales

En Gremlin, los escalones terminales son los escalones que hacen que una travesía sea enviada a Neptuno para su evaluación. En el modo de código de bytes, el escalón terminal hace que el controlador serialice y envíe el recorrido. En el modo script, el paso final forma parte de la cadena de consulta evaluada en el servidor. Los pasos finales son:

  • hasNext()— Devuelve true si los resultados están disponibles, de false lo contrario.

  • next()— Devuelve el siguiente resultado. Se lanza NoSuchElementException si no hay resultados.

  • next(n)— Devuelve los siguientes n resultados en forma de lista.

  • toList()— Devuelve todos los resultados en forma de lista. Devuelve una lista vacía si no hay resultados.

  • toSet()— Devuelve todos los resultados como un conjunto. Devuelve un conjunto vacío si no hay resultados.

  • iterate()— Repite todos los resultados sin devolverlos. Úselo para las mutaciones en las que no necesite el valor devuelto.

nota

Los GLV de cada idioma pueden proporcionar pasos finales adicionales específicos para su implementación. Consulte las páginas específicas de cada idioma para obtener más información.

Si desarrolla y prueba su código en un contexto, puede tener problemas. Por ejemplo, la consola Gremlin envía las consultas como scripts. El código puede comportarse de forma diferente en producción si lo despliegas en un contexto diferente, por ejemplo, a través del controlador Java mediante código de bytes.

importante

Asegúrate de probar el código de Gremlin usando el mismo modo de envío en el que se implementará, para evitar un comportamiento inesperado en las transacciones.