View a markdown version of this page

Testar o código do Gremlin no contexto em que você o implantará - Amazon Neptune

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Testar o código do Gremlin no contexto em que você o implantará

O Gremlin fornece várias maneiras para os clientes enviarem consultas ao servidor. Esses modos de envio diferem em como as consultas são avaliadas e como as transações se comportam. Essas diferenças podem levar a resultados inesperados se você desenvolver em um modo e implantar em outro.

Modo de script (envio baseado em string)

No modo script, o cliente envia a consulta inteira como uma string de texto para o servidor. O servidor avalia a string completa, incluindo todas as etapas do terminal, e transmite os resultados de volta para o cliente. As ferramentas e métodos a seguir usam o modo script:

No modo script, o cliente envia uma consulta como a seguinte para o servidor como uma string 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()");

O servidor avalia a consulta completa, inclusive.next(). Se não .next() encontrar resultados, o servidor gera um NoSuchElementException e a transação é revertida.

Modo de bytecode (objetos de travessia GLV)

No modo bytecode, o cliente cria um objeto transversal localmente usando uma Variante da Linguagem Gremlin (GLV). O driver serializa as etapas de travessia como bytecode e as envia ao servidor. Etapas do terminal, como .toList() ou .next() executadas no lado do cliente, para iterar os resultados retornados pelo servidor. Você pode usar o modo bytecode com Java, Python, Go JavaScript, .NET e outros TinkerPop-compliant drivers de terceiros adequados à versão do mecanismo Neptune usada.

No modo bytecode, a mesma consulta tem a seguinte aparência:

// 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();

O driver envia somente as etapas de travessia (g.V().addV().V()) como bytecode. O servidor avalia com êxito a travessia, confirma a transação e retorna o conjunto de resultados. Em seguida, o cliente chama .next() localmente para ler o conjunto de resultados. Se o conjunto de resultados estiver vazio, o cliente gera umNoSuchElementException, mas a transação já foi confirmada no servidor.

Diferenças de comportamento da transação

A diferença crítica entre esses modos é como as etapas do terminal afetam as transações:

  • Modo de script — O servidor avalia as etapas do terminal. Se uma etapa do terminal .next() falhar porque o conjunto de resultados está vazio, o servidor tratará a consulta como falhada e reverterá a transação. O servidor não persiste nenhuma mutação na mesma travessia (como). addV()

  • Modo de bytecode — O cliente avalia as etapas do terminal. O servidor avalia somente as etapas de travessia, confirma a transação com êxito e retorna os resultados. Se o cliente então chamar .next() um conjunto de resultados vazio, o resultado NoSuchElementException será apenas um erro do lado do cliente. A transação já foi confirmada, então o servidor persiste com qualquer mutação.

Etapas do terminal

No Gremlin, as etapas terminais são as etapas que fazem com que uma travessia seja submetida a Netuno para avaliação. No modo bytecode, a etapa do terminal aciona o driver para serializar e enviar a travessia. No modo script, a etapa do terminal faz parte da cadeia de caracteres de consulta avaliada no servidor. As etapas do terminal são:

  • hasNext()— Retorna true se os resultados estiverem disponíveis, false caso contrário.

  • next()— Retorna o próximo resultado. Lança NoSuchElementException se não houver resultados.

  • next(n)— Retorna n os próximos resultados como uma lista.

  • toList()— Retorna todos os resultados como uma lista. Retorna uma lista vazia se nenhum resultado existir.

  • toSet()— Retorna todos os resultados como um conjunto. Retorna um conjunto vazio se não houver resultados.

  • iterate()— Itera todos os resultados sem retorná-los. Use isso para mutações nas quais você não precisa do valor de retorno.

nota

Os GLVs de idiomas individuais podem fornecer etapas de terminal adicionais específicas para sua implementação. Consulte as páginas específicas do idioma para obter detalhes.

Se você desenvolver e testar seu código em um contexto, poderá ter problemas. Por exemplo, o console do Gremlin envia consultas como scripts. Seu código pode se comportar de forma diferente na produção se você o implantar em um contexto diferente, como por meio do driver Java usando bytecode.

Importante

Certifique-se de testar o código Gremlin usando o mesmo modo de envio no qual ele será implantado, para evitar um comportamento inesperado na transação.