Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Test del codice Gremlin nel contesto in cui verrà implementato

Gremlin offre ai client diversi modi per inviare domande al server. Queste modalità di invio differiscono nel modo in cui le interrogazioni vengono valutate e nel comportamento delle transazioni. Queste differenze possono portare a risultati inaspettati se si sviluppa in una modalità e si implementa in un'altra.

Modalità script (invio basato su stringhe)

In modalità script, il client invia l'intera query come stringa di testo al server. Il server valuta la stringa completa, inclusi tutti i passaggi del terminale, e trasmette i risultati al client. I seguenti strumenti e metodi utilizzano la modalità script:

In modalità script, il client invia una query come la seguente al server come stringa 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()");

Il server valuta la query completa, inclusi.next(). Se non .next() trova risultati, il server genera un NoSuchElementException e la transazione viene ripristinata.

modalità bytecode (oggetti trasversali GLV)

In modalità bytecode, il client crea un oggetto trasversale localmente utilizzando una Gremlin Language Variant (GLV). Il driver serializza le fasi di attraversamento come bytecode e le invia al server. Passaggi terminali come .toList() o .next() eseguiti sul lato client per iterare sui risultati restituiti dal server. È possibile utilizzare la modalità bytecode con Java, Python, Go JavaScript, .NET e altri TinkerPop-compliant driver di terze parti adatti alla versione del motore Neptune utilizzata.

In modalità bytecode, la stessa query ha il seguente aspetto:

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

Il driver invia solo i passaggi trasversali () g.V().addV().V() come bytecode. Il server valuta correttamente l'attraversamento, esegue il commit della transazione e restituisce il set di risultati. Il client chiama quindi .next() localmente per leggere il set di risultati. Se il set di risultati è vuoto, il client genera unNoSuchElementException, ma la transazione è già stata confermata sul server.

Differenze nel comportamento delle transazioni

La differenza fondamentale tra queste modalità è il modo in cui le fasi terminali influiscono sulle transazioni:

Fasi del terminale

In Gremlin, le fasi terminali sono le fasi che fanno sì che una traversata venga sottoposta a Neptune per la valutazione. In modalità bytecode, la fase terminale attiva il driver per serializzare e inviare l'attraversamento. In modalità script, la fase terminale fa parte della stringa di query valutata sul server. I passaggi del terminale sono:

Se sviluppate e testate il codice in un contesto, potete incorrere in problemi. Ad esempio, la console Gremlin invia le interrogazioni come script. Il codice potrebbe comportarsi diversamente in produzione se lo si distribuisce in un contesto diverso, ad esempio tramite il driver Java utilizzando il bytecode.