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 varias 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 finales, y envía los resultados al cliente. Las siguientes herramientas y métodos utilizan el modo script:

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 una 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 de forma local mediante una variante del lenguaje Gremlin (GLV). El controlador serializa los pasos de recorrido como código de bytes y los envía al servidor. Pasos de terminal, como .toList() .next() ejecutar en el lado del cliente, para repetir los resultados devueltos por el servidor. Puede utilizar el modo bytecode con Java, Python, Go JavaScript, .NET y otros TinkerPop-compliant controladores de terceros adecuados a la versión del motor de Neptune utilizada.

En el modo bytecode, la misma consulta tiene este 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 de recorrido (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 finales afectan a las transacciones:

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

  • Modo bytecode: 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, solo NoSuchElementException se trata de 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 un recorrido se envíe a Neptune para su evaluación. En el modo bytecode, el paso terminal hace que el controlador serialice y envíe el recorrido. En el modo script, el paso terminal forma parte de la cadena de consulta evaluada en el servidor. Los pasos del terminal son:

  • hasNext()— Regresa true si los resultados están disponiblesfalse; de 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()— Itera todos los resultados sin devolverlos. Úselo para las mutaciones en las que no necesite el valor devuelto.

nota

Los GLV en distintos idiomas pueden proporcionar pasos terminales adicionales específicos para su implementación. Consulte las páginas específicas del 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 podría comportarse de forma diferente en producción si lo despliega en un contexto diferente, por ejemplo, mediante el controlador Java mediante bytecode.

importante

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