

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Testen Sie den Gremlin-Code in dem Kontext, in dem Sie ihn einsetzen werden
<a name="best-practices-gremlin-console-glv-differences"></a>

Gremlin bietet Clients mehrere Möglichkeiten, Anfragen an den Server zu senden. Diese Übermittlungsmodi unterscheiden sich darin, wie Abfragen ausgewertet werden und wie sich Transaktionen verhalten. Diese Unterschiede können zu unerwarteten Ergebnissen führen, wenn Sie in einem Modus entwickeln und in einem anderen bereitstellen.

**Skriptmodus (auf Zeichenketten basierende Übermittlung)**  
Im Skriptmodus sendet der Client die gesamte Abfrage als Textzeichenfolge an den Server. Der Server wertet die gesamte Zeichenfolge, einschließlich aller *Terminalschritte, aus* und streamt die Ergebnisse zurück an den Client. Die folgenden Tools und Methoden verwenden den Skriptmodus:
+ [Gremlin Console](access-graph-gremlin-console.md) — wenn Sie den Befehl verwenden `:remote`
+ [Notizbuch mit Neptun-Diagramm](graph-notebooks.md)
+ [HTTP mit AWS SDK oder AWS CLI](access-graph-gremlin-rest.md)
+ Senden von Abfragezeichenfolgen über TinkerPop Treiber (z. B. `client.submit("g.V().count()")` in Java)

Im Skriptmodus sendet der Client eine Abfrage wie die folgende als vollständige Zeichenfolge an den Server:

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

Der Server wertet die vollständige Abfrage aus, einschließlich`.next()`. Wenn keine `.next()` Ergebnisse gefunden werden, löst der Server eine aus `NoSuchElementException` und die Transaktion wird *zurückgesetzt*.

**Bytecode-Modus (GLV-Traversal-Objekte)**  
Im Bytecode-Modus erstellt der Client ein Traversal-Objekt lokal mithilfe einer Gremlin Language Variant (GLV). Der Treiber serialisiert die Durchlaufschritte als Bytecode und sendet sie an den Server. Terminalschritte wie `.toList()` oder werden auf der *Client-Seite `.next()` ausgeführt, um über die vom Server zurückgegebenen* Ergebnisse zu iterieren. Sie können den Bytecode-Modus mit [Java](access-graph-gremlin-java.md) -, [Python](access-graph-gremlin-python.md) -, [Go](access-graph-gremlin-go.md) -, [.NET](access-graph-gremlin-dotnet.md) - und anderen TinkerPop-compliant Treibern von Drittanbietern verwenden [JavaScript](access-graph-gremlin-node-js.md), die für die verwendete Neptune-Engine-Version geeignet sind.

Im Bytecode-Modus sieht dieselbe Abfrage wie folgt aus:

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

Der Treiber sendet nur die Traversalschritte () `g.V().addV().V()` als Bytecode. Der Server wertet die Durchquerung erfolgreich aus, schreibt die Transaktion fest und gibt die Ergebnismenge zurück. Der Client ruft dann `.next()` lokal auf, um aus der Ergebnismenge zu lesen. Wenn die Ergebnismenge leer ist, löst der Client eine aus`NoSuchElementException`, aber die Transaktion wurde *bereits auf dem Server festgeschrieben*.

**Unterschiede im Transaktionsverhalten**  
Der entscheidende Unterschied zwischen diesen Modi besteht darin, wie sich Terminalschritte auf Transaktionen auswirken:
+ **Skriptmodus** — Der Server wertet die Terminalschritte aus. Wenn ein Terminalschritt wie z. B. `.next()` fehlschlägt, weil die Ergebnismenge leer ist, behandelt der Server die Abfrage als fehlgeschlagen und setzt die Transaktion *zurück*. Der Server behält keine Mutationen bei derselben Durchquerung bei (z. B.). `addV()`
+ **Bytecode-Modus — Der Client wertet** die Terminalschritte aus. Der Server wertet nur die Durchlaufschritte aus, schreibt die Transaktion erfolgreich fest und gibt Ergebnisse zurück. Wenn der Client dann eine leere Ergebnismenge `.next()` aufruft, `NoSuchElementException` ist das Ergebnis nur ein clientseitiger Fehler. Die Transaktion wurde bereits festgeschrieben, sodass der Server alle Mutationen *beibehält.*

**Schritte im Terminal**  
In Gremlin sind [terminale Schritte die Schritte](https://tinkerpop.apache.org/docs/current/reference/#terminal-steps), die dazu führen, dass eine Traversal zur Auswertung an Neptune übermittelt wird. Im Bytecode-Modus veranlasst der Terminalschritt den Treiber, den Traversal zu serialisieren und zu senden. Im Skriptmodus ist der Terminalschritt Teil der Abfragezeichenfolge, die auf dem Server ausgewertet wird. Die Terminalschritte sind:
+ `hasNext()`— Gibt zurück`true`, ob Ergebnisse verfügbar sind, `false` andernfalls.
+ `next()`— Gibt das nächste Ergebnis zurück. Wirft, `NoSuchElementException` wenn keine Ergebnisse vorhanden sind.
+ `next(n)`— Gibt die nächsten {{n}} Ergebnisse als Liste zurück.
+ `toList()`— Gibt alle Ergebnisse als Liste zurück. Gibt eine leere Liste zurück, wenn keine Ergebnisse vorhanden sind.
+ `toSet()`— Gibt alle Ergebnisse als Satz zurück. Gibt eine leere Menge zurück, wenn keine Ergebnisse vorhanden sind.
+ `iterate()`— Iteriert alle Ergebnisse, ohne sie zurückzugeben. Verwenden Sie dies für Mutationen, bei denen Sie den Rückgabewert nicht benötigen.

**Anmerkung**  
GLVs für einzelne Sprachen können zusätzliche terminale Schritte bereitstellen, die für ihre Implementierung spezifisch sind. Einzelheiten finden Sie auf den sprachspezifischen Seiten.

Wenn Sie Ihren Code in einem Kontext entwickeln und testen, können Probleme auftreten. Beispielsweise sendet die Gremlin-Konsole Abfragen als Skripte. Ihr Code kann sich in der Produktion anders verhalten, wenn Sie ihn in einem anderen Kontext bereitstellen, z. B. über den Java-Treiber mithilfe von Bytecode.

**Wichtig**  
Stellen Sie sicher, dass Sie den Gremlin-Code im gleichen Übertragungsmodus testen, in dem er bereitgestellt wird, um unerwartetes Transaktionsverhalten zu vermeiden.