Graph Databases in Action by Dave Bechberger & Josh Perryman

Author:Dave Bechberger & Josh Perryman [Bechberger, Dave & Perryman, Josh]
Language: eng
Format: epub
Publisher: Manning Publications Co.
Published: 0101-01-01T00:00:00+00:00

6.4 Adding, modifying, and deleting data

Among the most common tasks applications perform are adding, updating, and deleting data. In chapter 4, we went through the process of creating these traversals, and in this section, we walk through each option and show some of the unique aspects of how to process these within a graph application.

6.4.1 Adding vertices

In chapter 4, we went through how to mutate our graph to add data. Let’s look at adding a new vertex to our graph. Remembering back, we wrote a traversal to add a person to our graph:

g.addV('person').property('first_name', 'Dave')

Now, how do we go about taking that traversal and turning it into code? In the last section, we showed how simple it was to use the GLV in our code compared to the JDBC approach or to a Groovy script. What we didn’t discuss was precisely how we translated the Gremlin script we used in the Gremlin Console to the Java code, so we’re going to rectify that now.

Translating your Gremlin traversal into the GLV

To translate the string-based traversal to a GLV-type traversal, we take each step in the string traversal and replace it with an identically named Java method. Yes, seriously, that’s it! It’s a bit anticlimactic, isn’t it? The good news is we really aren’t kidding. Because Gremlin is built on the JVM, the syntax is the same, at least in Java. The other piece that we do need to add is the common imports (http://mng.bz/4BMB). While we haven’t needed to include any of these so far, the imports are required to write more complex traversals.

We know we said that it’s as easy as copying and pasting our script to translate from the Gremlin Console to an application, right? Well, in Java, that’s also the case, but the same isn’t always true for other languages.

Each GLV is built to provide a native experience in the target language. This native experience also means that we inherit the native casing, reserved words, and other features of each language. So, for example, if we build our application in .NET, we need to capitalize the first letter of each method instead of using camel case (e.g., HasNext(), not hasNext()). Or, if we use Python, we must postfix an underscore (_) to functions such as and(), as(), from(), and so forth because these are reserved words in Python (e.g., from_()).

Moving from GLV to Java

In our opinion, the ability to quickly build and maintain our traversals consistently with native language standards far outweighs the minor inconsistencies across target languages. Using this methodology, let’s take the Gremlin traversal we used in the console:

g.addV('person').property('first_name', 'Dave')

Translating that into a Java statement, this becomes

g.addV("person").property("first_name", name).next();

A keen observer will notice that we changed from single quotes to double quotes. Gremlin, owing to its Groovy roots, accepts either double or single quotes for strings. But we’re using the Java GLV, and Java has stronger opinions, leading to the double quotes for strings.

Well, that was pretty easy, but what does our statement return? Remembering back to when we ran this in the Gremlin Console, we get a reference to a vertex:

g.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.