Managing Data in xGT

The xGT tool implements a strongly-typed, property graph data model. The fundamental building blocks of this model are frames, tabular representations of data with prescribed data types. In order to create a frame, a user specifies the names and data types of each property (called a schema) as well as any other information specific to that structure (for instance, the key property for a vertex frame).

When a user wants to load data, they do so by loading it directly into an existing frame, and xGT provides support for a variety of different data sources and loading options. Users can get frame objects either from the output of the create_*_frame methods or by explicitly calling the get_*_frame method with the name or names of the frames the user wants.

# *conn* is an open connection to the server.
rep_to = conn.get_edge_frame('ReportsTo')

The rest of this document assumes you have set up a graph component in a python variable in a way that is similar to rep_to above.

Getting data in to xGT

There are two ways to get data into xGT: across a network and from a filesystem. All forms of getting data into xGT can be expressed by calling the load() method in the xgt python module.

The signature of the load method is: entity.load(paths, headerMode=xgt.HeaderMode.NONE), where entity may be a table, vertex, or edge frame.

The paths parameter describes where xGT can find the CSV file or files. The headerMode parameter is a flag indicating whether or not the CSV data sources contain a first line that is a header (i.e., column names) and how it should be handled. There are four modes:

1. Reading from the client filesystem

This method is the most straightforward. The path parameter simply is an absolute or relative path on the client's local filesystem.

vertex_frame.load('/data/path/my_vertices.csv')
edge_frame.load('/data/path/my_edges.csv', '/data/path/my_other_edges.csv')

These load calls request xgt to search the local filesystem for the files, then send them to the xGT server. Note that if the server is running on a separate system, the data will be shipped over the network as part of these method calls.

2. Reading from the server filesystem

This method is is essentially a request for the xGT server to go looking for and ingest the CSV files. The path is preceded with a protocol specification telling xgt to pass off the request to the server (the xGT daemon).

frame.load('xgtd://data/path/example.csv')
frame.load(['xgtd://data/path/myfirst.csv', 'xgtd://data/path/mysecond.csv'])

3. Reading from a URL

This method asks the xGT server to retrieve CSV-formatted data from a URL. The protocol can be either http or https.

frame.load('http://www.example.com/data/path/example.csv')
frame.load(['http://www.example.com/data/myfirst.csv', 'https://www.example.com/data/mysecond.csv'])

4. Reading from an AWS S3 bucket

This method asks the xGT server to pull CSV-formatted data directly from an AWS S3 bucket.

frame.load('s3://my-s3-bucket/data/path/example.csv')
frame.load(['s3://my-s3-bucket/data/myfirst.csv', 's3://my-s3-bucket/data/mysecond.csv'])

5. Handling Ingest Errors

If an error occurs during ingesting a valid file, the CSV reader will create a table labeled with the frame name + _error that contains a list of lines that failed with corresponding error messages. Python will throw an error containing the table name when this happens. At this point the error frame can be read.

Each row of the table corresponds to a line that failed to read. The first column contains the error message. The second column contains the line that failed to ingest if available. The next columns contain the data that was encoded before the failure occurred. This will usually be empty since most errors occur before encoding.

frame = conn.get_table_frame('Employee')
frame.load('test.csv')
... # An error occurs and exception gets thrown during the load.
error_frame = conn.get_table_frame('Employee_error')

Getting data out of xGT

The save() method is used to request xGT to write data into a CSV file on either the client or server filesystem.

The signature of the save method is: entity.save(path, offset=0, length=None, headers=False), where entity may be a table, vertex, or edge.

This is the preferred method for extracting the result of a query (saving from the result table of a MATCH query).

There are only two variants of the path for a save method.

1. Saving to the client filesystem

This method simply provides an absolute or relative path to the client's local filesystem

frame.save('../data/path/example.csv')
frame.save('../data/interesting.data.csv', offset=10, length=100, headers=True)

Note that the searchResult save pulls at most 100 rows, starting from row 10 of a result table, and creates a CSV file with the column names included. This file can be read directly into some other analytic tool such as MS Excel.

2. Saving to the server filesystem

This method provides an absolute or relative path on the server's filesystem as indicated by the xgtd:// protocol.

frame.save('xgtd://../data/path/example.csv')
frame.save('xgtd://../data/interesting.data.csv', offset=10, length=1000000, headers=True)

This method should be used when you know the size of the data is prohibitively large. It is certainly possible to copy the data elsewhere after saving on to the server filesystem.