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á
<a name="best-practices-gremlin-console-glv-differences"></a>

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:
+ [Console Gremlin](access-graph-gremlin-console.md) — ao usar o comando `:remote`
+ [Caderno gráfico de Netuno](graph-notebooks.md)
+ [HTTP com AWS SDK ou CLI AWS](access-graph-gremlin-rest.md)
+ Envio de cadeias de caracteres de consulta por meio de TinkerPop drivers (por exemplo, usando `client.submit("g.V().count()")` em Java)

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](access-graph-gremlin-java.md), [Python](access-graph-gremlin-python.md), [Go [JavaScript](access-graph-gremlin-node-js.md)](access-graph-gremlin-go.md), [.NET](access-graph-gremlin-dotnet.md) 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 um`NoSuchElementException`, 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](https://tinkerpop.apache.org/docs/current/reference/#terminal-steps) 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.