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 na forma como as consultas são avaliadas e no comportamento das transações. 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 sequência de texto para o servidor. O servidor avalia a sequência de caracteres completa, incluindo todas as etapas do terminal, e transmite os resultados de volta para o cliente. As ferramentas e os métodos a seguir usam o modo de 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, incluindo.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 de travessia localmente usando uma Variante da Linguagem Gremlin (GLV). O driver serializa as etapas de travessia como bytecode e as envia para o 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 motorista envia somente as etapas de travessia (g.V().addV().V()) como bytecode. O servidor avalia com sucesso a travessia, confirma a transação e retorna o conjunto de resultados. Em seguida, o cliente liga .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 no 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 trata a consulta como falha e reverte 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 um conjunto .next() 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 em todas as mutações.

Etapas do terminal

No Gremlin, as etapas terminais são as etapas que fazem com que uma travessia seja enviada 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 sequência 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 não existirem resultados.

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

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

nota

Os GLVs de linguagem individual 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ê implantá-lo 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 em que ele será implantado, para evitar um comportamento inesperado da transação.