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

Gremlin bietet Clients mehrere Möglichkeiten, Abfragen 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 (zeichenfolgenbasierte Einreichung)

Im Skriptmodus sendet der Client die gesamte Abfrage als Textzeichenfolge an den Server. Der Server wertet die komplette Zeichenfolge einschließlich aller Endschritte aus und streamt die Ergebnisse zurück an den Client. Die folgenden Tools und Methoden verwenden den Skriptmodus:

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 rückgängig gemacht.

Bytecode-Modus (GLV-Traversal-Objekte)

Im Bytecode-Modus erstellt der Client lokal ein Traversal-Objekt mithilfe einer Gremlin Language Variant (GLV). Der Treiber serialisiert die Traversierungsschritte als Bytecode und sendet sie an den Server. Terminalschritte wie .toList() oder werden auf der Clientseite .next() ausgeführt, um anhand der vom Server zurückgegebenen Ergebnisse zu iterieren. Sie können den Bytecode-Modus mit Java, Python, Go , .NET und anderen TinkerPop-compliant Treibern von Drittanbietern verwenden JavaScript, 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 Traversal Steps () g.V().addV().V() als Bytecode. Der Server wertet den Traversal 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 einen ausNoSuchElementException, 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:

Schritte im Terminal

In Gremlin sind Endstufen die Schritte, die dazu führen, dass Neptun eine Traversierung zur Auswertung ü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:

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