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 richieste al server. Queste modalità di invio differiscono nel modo in cui le richieste 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 eventuali 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 l'intera query, inclusi.next(). Se non .next() trova risultati, il server genera un NoSuchElementException e la transazione viene annullata.

Modalità bytecode (oggetti che attraversano GLV)

In modalità bytecode, il client crea un oggetto di attraversamento localmente utilizzando una Gremlin Language Variant (GLV). Il driver serializza i passaggi di attraversamento come bytecode e li invia al server. I passaggi del terminale, ad esempio, .toList() .next() vengono 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 di attraversamento () 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 eseguita 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 la serializzazione e l'invio dell'attraversamento. In modalità script, la fase terminale fa parte della stringa di interrogazione valutata sul server. Le fasi terminali sono:

Se sviluppate e testate il codice in un unico contesto, potreste incorrere in problemi. Ad esempio, la console Gremlin invia le query 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.