Modifying a Graph Schema
After a graph schema has been created , it can be modified. Data already stored in the graph and which is not logically part of the change will be retained. For example, if you had 100 Book vertices and then added an attribute to the Book schema, you would still have 100 Books, with default values for the new attribute. If you dropped a Book attribute, you still would have all your books, but one attribute would be gone.
To safely update the graph schema, the user should follow this procedure:
  • Create a SCHEMA_CHANGE JOB, which defines a sequence of ADD, ALTER and/or DROP statements.
  • Run the SCHEMA_CHANGE JOB (i.e. RUN SCHEMA_CHANGE JOB job_name), which will do the following:
    • Attempt the schema change.
    • If the change is successful, invalidate any loading job or query definitions which are incompatible with the new schema.
    • if the change is unsuccessful, report the failure and return to the state before the attempt.
A schema change will invalidate any loading jobs or query jobs which relate to an altered part of the schema. Specifically:
  • A loading job becomes invalid if it refers to a vertex or and an edge which has been dropped (deleted) or altered .
  • A query becomes invalid if it refers to a vertex, and edge, or an attribute which has been dropped .
Invalid loading jobs are dropped, and invalid queries are uninstalled. After the schema update, the user will need to create and install new load and query jobs based on the new schema.
Jobs and queries for unaltered parts of the schema will still be available and do not need to be reinstalled. However, even though these jobs are valid (e.g., they can be run), the user may wish to examine whether they still perform the preferred operations (e.g., do you want to run them?)
Load or query operations which begin before the schema change will be completed based on the pre-change schema. Load or query operations which begin after the schema change, and which have not been invalidated, will be completed based on the post-change schema.

Global vs. Local Schema Changes

Only a superuser or globaldesigner can add, alter, or drop global vertex types or global edge types, which are those that are created using CREATE VERTEX or CREATE ... EDGE. This rule applies even if the vertex or edge type is used in only one graph. To make these changes, the user uses a GLOBAL SCHEMA_CHANGE JOB.
An admin or designer user can add, alter, or drop local vertex types or local edge types which are created in the context of that graph. Local vertex and edge types are created using an ADD statement inside a SCHEMA_CHANGE JOB. To alter or drop any of these local types, the admin user uses a regular SCHEMA_CHANGE JOB.
Local graphs can define vertex and edge types independently of the vertex and edge types in other graph. That is, the same name can be used in different graphs for (different) vertex or edge types.
It is even permitted for a local graph and the global graph to use the same name for their own vertex or edge types, as long as the global vertex/edge type is not used within the local graph.
The two types of schema change jobs are described below.

CREATE SCHEMA_CHANGE JOB (local)

The CREATE SCHEMA_CHANGE JOB block defines a sequence of ADD, ALTER, and DROP statements for changing a particular graph. It does not perform the schema change.
CREATE SCHEMA_CHANGE JOB syntax
1
CREATE SCHEMA_CHANGE JOB job_name FOR GRAPH graph_name {
2
[sequence of DROP, ALTER, and ADD statements, each line ending with a semicolon]
3
}
Copied!
One use of CREATE SCHEMA_CHANGE JOB is to define an additional vertex type and edge type to be the structure for a secondary index. For example, if you wanted to index the postalCode attribute of the User vertex, you could create a postalCode_idx (PRIMARY_ID id string, code string) vertex type and hasPostalCode (FROM User, TO postalCode_idx) edge type. Then create an index structure having one edge from each User to a postalCode_idx vertex.
By its nature, a SCHEMA_CHANGE JOB may contain multiple statements. If the job block is used in the interactive GSQL shell, then the BEGIN and END commands should be used to permit the SCHEMA_CHANGE JOB to be entered on several lines. if the job is stored in a command file to be read in batch mode, then BEGIN and END are not needed.
Remember to include a semicolon at the end of each DROP, ALTER, or ADD statement within the JOB block.
If a SCHEMA_CHANGE JOB defines a new edge type which connects to a new vertex type, the ADD VERTEX statement should precede the related ADD EDGE statement. However, the ADD EDGE and ADD VERTEX statements can be in the same SCHEMA_CHANGE JOB.

ADD VERTEX | EDGE (local)

The ADD statement defines a new type of vertex or edge and automatically adds it to a graph schema. The syntax for the ADD VERTEX | EDGE statement is analogous to that of the CREATE VERTEX | EDGE | GRAPH statements. It may only be used within a SCHEMA_CHANGE JOB.
ADD VERTEX / UNDIRECTED EDGE / DIRECTED EDGE
1
ADD VERTEX v_type_name (PRIMARY_ID id type [',' attribute_list]) [WITH STATS '=' "none"|"outdegree_by_edgetype"];
2
ADD UNDIRECTED EDGE e_type_name (FROM v_type_name',' TO v_type_name [',' edge_attribute_list])
3
ADD DIRECTED EDGE e_type_name (FROM v_type_name',' TO v_type_name [',' edge_attribute_list])
4
[WITH REVERSE_EDGE '=' "rev_name"];
Copied!

ALTER VERTEX | EDGE

The ALTER statement adds attributes to or removes attributes from an existing vertex type or edge type. It may only be used within a SCHEMA_CHANGE JOB. The basic format is as follows:
ALTER VERTEX / EDGE
1
ALTER VERTEX|EDGE object_type_name ADD|DROP (attribute_list);
Copied!

ALTER ... ADD

ALTER ... ADD can add attributes to vertex or edge types.
Added attributes are appended to the end of the schema. The new attributes may include DEFAULT fields. To add attributes to a vertex type, the syntax is as follows:
ALTER VERTEX ... ADD
1
ALTER VERTEX vertex_type_name ADD
2
ATTRIBUTE (attribute_name type [DEFAULT default_value]
3
[',' attribute_name type [DEFAULT default_value]]* );
Copied!
For example:
1
ALTER VERTEX Company ADD ATTRIBUTE (industry
2
STRING, marketcap DOUBLE)
Copied!
To add to an edge's endpoint vertex types or attributes, the syntax is as follows:
ALTER EDGE... ADD
1
ALTER EDGE edge_type_name ADD
2
[ATTRIBUTE (attribute_name type [DEFAULT default_value]
3
[',' attribute_name type [DEFAULT default_value]]* )];
Copied!

ALTER EDGE .. ADD PAIR

ALTER EDGE ... ADD PAIR adds one or more edge pairs, which refer to the FROM and TO vertex types of an edge type. To add an edge pair, put the vertex type names in parentheses after keywords FROM and TO.
Syntax
1
ALTER EDGE edgeType ADD PAIR
2
"(" FROM vertexType, TO vertexType (| FROM vertexType, TO vertexType)* ")
Copied!
Example
In the example below, the first statement in the schema change job will add an edge pair (FROM person, TO company) to the edge type visit. The second example adds two edge pairs to the edge type has_pet; the edge type can now connect both person and dog vertices, as well as person and bird vertices.
1
CREATE SCHEMA_CHANGE JOB job2 FOR GRAPH example_graph {
2
ALTER EDGE visit ADD PAIR (FROM person, TO company);
3
ALTER EDGE has_pet ADD PAIR (FROM person, TO dog | FROM person, TO bird);
4
}
Copied!

ALTER ... DROP

The syntax for ALTER ... DROP is analogous to that of ALTER ... ADD.
ALTER ... DROP
1
ALTER VERTEX|EDGE object_type_name DROP ATTRIBUTE (
2
attribute_name [',' attribute_name]* );
Copied!

ALTER VERTEX ... WITH (Beta)

The statement ALTER VERTEX WITH TAGGABLE is used to mark a vertex type as taggable or untaggable. Vertex types are untaggable by default. When a vertex type is marked as taggable, the vertex type can be used to create a tag-based graph. Additionally, users with the tag-access privilege can tag vertices whose vertex type is marked as taggable.
ALTER VERTEX WITH TAGGABLE
1
ALTER VERTEX v_type_name WITH TAGGABLE = ("true" | "false")
Copied!

DROP VERTEX | EDGE (local)

The DROP statement removes the specified vertex type or edge type from the database dictionary. The DROP statement should only be used when graph operations are not in progress.
drop vertex / edge
1
DROP VERTEX v_type_name [',' v_type_name]*
2
DROP EDGE e_type_name [',' e_type_name]*
Copied!

DROP TUPLE

For tuples that are defined within a graph schema, you can drop them by using the following command.
drop tuple
1
DROP TUPLE tuple_name [',' tuple_name]*
Copied!

ADD TAG

ADD TAG defines a tag for the graph. Tags can be used to create tag-based graphs, allowing for finer grain access control.
Syntax for ADD TAG
1
ADD TAG <tag_name> [DESCRIPTION <tag_description>]
Copied!

DROP TAG

DROP TAG drops a tag or multiple tags from the schema, and deletes the tag from each vertex to which it is attached. DROP TAG cannot be run if the tag to be dropped is used in the definition of a tag-based graph; the graph must be dropped first.
Syntax for DROP TAG
1
DROP TAG <tag_name> ["," <tag_name>]*
Copied!

RUN SCHEMA_CHANGE JOB

RUN SCHEMA_CHANGE JOB job_name performs the schema change job. After the schema has been changed, the GSQL system checks all existing GSQL queries. If an existing GSQL query uses a dropped vertex, edge, or attribute, the query becomes invalid, and GSQL will show the message "Query query_name becomes invalid after schema update, please update it.".
Below is an example. The schema change job add_reviews adds a Review vertex type and two edge types to connect reviews to users and books, respectively.
SCHEMA_CHANGE JOB example
1
USE GRAPH Book_rating
2
CREATE SCHEMA_CHANGE JOB add_reviews FOR GRAPH Book_rating {
3
ADD VERTEX Review (PRIMARY_ID id UINT, review_date DATETIME, url STRING);
4
ADD UNDIRECTED EDGE wrote_review (FROM User, TO Review);
5
ADD UNDIRECTED EDGE review_of_book (FROM Review, TO Book);
6
}
7
RUN SCHEMA_CHANGE JOB add_reviews
Copied!

DROP SCHEMA_CHANGE JOB

To drop (remove) a schema change job, run DROP JOB schema_change_job name from the GSQL shell. The specific schema change job will be removed from GSQL. Refer to the Creating a Loading Job page for more information about dropping jobs.
1
GSQL > USE GRAPH Book_rating
2
GSQL > DROP JOB local_schema_change123
3
The job local_schema_change_change123 is dropped!
Copied!

USE GLOBAL

The USE GLOBAL command changes a superuser's mode to Global mode. In global mode, a superuser can define or modify global vertex and edge types, as well as specifying which graphs use those global types. For example, the user should run USE GLOBAL before creating or running a GLOBAL SCHEMA_CHANGE JOB.

CREATE GLOBAL SCHEMA_CHANGE JOB

The CREATE GLOBAL SCHEMA_CHANGE JOB block defines a sequence of ADD, ALTER, and DROP statements that modify either the attributes or the graph membership of global vertex or edge types. Unlike the non-global schema change job, the header does not include a graph name. However, the ADD/ALTER/DROP statements in the body do mention graphs.
CREATE GLOBAL SCHEMA_CHANGE JOB syntax
1
CREATE GLOBAL SCHEMA_CHANGE JOB job_name {
2
[sequence of global DROP, ALTER, and ADD statements, each line ending with a semicolon]
3
}
Copied!
Although both global and local schema change jobs have ADD and DROP statements, they have different meanings. The table below outlines the differences.
Local
Global
ADD
Defines a new local vertex/edge type; adds it to the graph's domain
Adds one or more existing global vertex/edge types to a graph's domain.
DROP
Deletes a local vertex/edge type and its vertex/edge instances
Removes one or more existing global vertex/edge types from a graph's domain.
ALTER
Adds or drops attributes from a local vertex/edge type.
Adds or drops attributes from a global vertex/edge type, which may affect several graphs.
Remember to include a semicolon at the end of each DROP, ALTER, or ADD statement within the JOB block.

ADD VERTEX | EDGE (global)

The ADD statement adds existing global vertex or edge types to one of the graphs.
ADD VERTEX / UNDIRECTED EDGE / DIRECTED EDGE (Global)
1
ADD VERTEX v_type_name [',' v_type_name...] TO GRAPH gname;
2
ADD EDGE e_type_name [',' e_type_name...] TO GRAPH gname;
Copied!

ALTER VERTEX | EDGE

The ALTER statement is used to add attributes to or remove attributes from an existing global vertex type or edge type. The ALTER VERTEX / EDGE syntax for global schema changes is the same as that for local schema change jobs.
The ALTER statement is used to add attributes to or remove attributes from an existing vertex type or edge type. It can also be used to add or remove source (FROM) vertex types or destination (TO) vertex types of an edge type. It may only be used within a SCHEMA_CHANGE JOB. The basic format is as follows:
ALTER VERTEX / EDGE
1
ALTER VERTEX|EDGE object_type_name ADD|DROP (attribute_list);
Copied!

ALTER ... ADD

Added attributes are appended to the end of the schema. The new attributes may include DEFAULT fields. To add attributes to a vertex type, the syntax is as follows:
ALTER VERTEX ... ADD
1
ALTER VERTEX vertex_type_name ADD
2
ATTRIBUTE (attribute_name type [DEFAULT default_value]
3
[',' attribute_name type [DEFAULT default_value]]* );
Copied!
For example:
1
ALTER VERTEX Company ADD ATTRIBUTE (industry
2
STRING, marketcap DOUBLE)
Copied!
To add to an edge's endpoint vertex types or attributes, the syntax is as follows:
ALTER EDGE... ADD
1
ALTER EDGE edge_type_name ADD
2
[FROM (vertex_type_name [','vertex_type_name])]
3
[TO (vertex_type_name [','vertex_type_name])]
4
[ATTRIBUTE (attribute_name type [DEFAULT default_value]
5
[',' attribute_name type [DEFAULT default_value]]* )];
Copied!
For example:
1
ALTER EDGE Like ADD TO (Animal) ATTRIBUTE (suggested_by STRING)
Copied!

ALTER EDGE .. ADD PAIR

ALTER EDGE ... ADD PAIR adds one or more edge pairs, which refer to the FROM and TO vertex types of an edge type. To add an edge pair, put the vertex type names in parentheses after keywords FROM and TO.
Syntax
1
ALTER EDGE edgeType ADD PAIR
2
"(" FROM vertexType, TO vertexType (| FROM vertexType, TO vertexType)* ")
Copied!
Example
In the example below, the first statement in the schema change job will add an edge pair (FROM person, TO company) to the edge type visit. The second example adds two edge pairs to the edge type has_pet; the edge type can now connect both person and dog vertices, as well as person and bird vertices.
1
CREATE GLOBAL SCHEMA_CHANGE JOB job2 FOR GRAPH example_graph {
2
ALTER EDGE visit ADD PAIR (FROM person, TO company);
3
ALTER EDGE has_pet ADD PAIR (FROM person, TO dog | FROM person, TO bird);
4
}
Copied!

ALTER ... DROP

The syntax for ALTER ... DROP is analogous to that of ALTER ... ADD.
ALTER ... DROP
1
ALTER VERTEX|EDGE object_type_name DROP ATTRIBUTE (
2
attribute_name [',' attribute_name]* );
Copied!

ALTER VERTEX ... WITH (Beta)

The statement ALTER VERTEX WITH TAGGABLE is used to mark a vertex type as taggable or untaggable. Vertex types are untaggable by default. When a vertex type is marked as taggable, the vertex type can be used to create a tag-based graph. Additionally, users with the tag-access privilege can tag vertices whose vertex type is marked as taggable.
ALTER VERTEX WITH TAGGABLE
1
ALTER VERTEX v_type_name WITH TAGGABLE = ("true" | "false")
Copied!

DROP VERTEX | EDGE (global)

The DROP statement removes specified global vertex or edge types from one of the graphs. The command does not delete any data.
drop vertex / edge
1
DROP VERTEX v_type_name [',' v_type_name...] FROM GRAPH gname;
2
DROP EDGE e_type_name [',' e_type_name...] FROM GRAPH gname;
Copied!

RUN GLOBAL SCHEMA_CHANGE JOB

RUN GLOBAL SCHEMA_CHANGE JOB job_name performs the global schema change job. After the schema has been changed, the GSQL system checks all existing GSQL queries. If an existing GSQL query uses a dropped vertex, edge, or attribute, the query becomes invalid, and GSQL will show the message "Query query_name becomes invalid after schema update, please update it.".
Below is an example. The schema change alter_friendship_make_library drops the on_date attribute from the friend_of edge and adds Book type to the library graph.
GLOBAL SCHEMA_CHANGE JOB example
1
USE GLOBAL
2
CREATE GRAPH library()
3
CREATE GLOBAL SCHEMA_CHANGE JOB alter_friendship_make_library {
4
ALTER EDGE friend_of DROP ATTRIBUTE (on_date);
5
ADD VERTEX Book TO GRAPH library;
6
}
7
RUN GLOBAL SCHEMA_CHANGE JOB alter_friendship_make_library
Copied!

DROP GLOBAL SCHEMA_CHANGE JOB

Global schema change jobs can be dropped by using the DROP JOB command. Refer to the Creating a Loading Job page for more information about dropping jobs.
DROP GLOBAL SCHEMA_CHANGE JOB example
1
USE GLOBAL
2
DROP JOB alter_friendship_make_library
Copied!

DROP ALL

The DROP ALL command clears all graph data, all graph schemas, all loading jobs, and all queries. It should only be used when the intent is to erase an entire database design and to start over.
This command is only available to superusers and only when they are in global mode.
Last modified 2mo ago