persontype, and vertices of
posttype. Two tags (A and B) are used to tag them. For example, vertex 1 and vertex 9 both have tag A. Vertex 3 and vertex 11 both have tag A and B. A tag-based graph named
tagAwill only present to its users those base graph vertices that have tag A (the bottom-left graph). The other tag-based graph named
tagBwill only present to its users those base graph vertices that have tag B (the bottom-right graph).
WRITE_DATAprivileges on the base graph can create and run a DML query that sets tags on selected individual vertices.
ACCESS_TAGprivileges on the base graph can create and run a loading job that explicitly sets tags on the newly loaded base graph vertices.
querywriter) can create an ordinary loading or upsert job which inserts new vertices. The new vertices will be automatically tagged according to the tag-based graph's schema definition.
queryreaderbuilt-in roles) can query and update the tag-based graph as they would do any other graph. The data filtering for querying or data tagging for insertion is applied automatically.
ADD TAGbefore it can be used. Each base graph defines its own set of tags. However, there is a global maximum number of different tags, currently set at 64.
ADD TAGcan only be used inside a
SCHEMA_CHANGE JOB. An example is below:
lsto see a list of defined tags:
DROP TAGcommand not only removes the given tag(s) from the catalog of available tags, but also deletes them from each vertex to which it is attached. You can drop multiple tags in one statement.
DROP TAGalso needs to be inside a
TAGGABLEis a boolean property of a vertex type that can be set with
CREATE VERTEXinitially or with
ALTER VERTEXin a schema change job:
WITHclause below when creating a vertex type:
socialNetgraph, create a tag-based graph called
personvertices which are tagged '
vip'. Also include all
postvertices and all
&operator to combine the tags:
mixedNetwill only include the
personvertices having both the
viptags, and posts having all three of the
designer) can create and run a DML query that sets tags on selected individual vertices.
designer) can create and run a loading job that explicitly sets tags on the newly loaded vertices.
querywriter) can create an ordinary Loading or Upsert Job which inserts new vertices. The new vertices will be automatically tagged according to the tag-based graph's schema definition.
FROMclause of a
SELECTstatement); they cannot be applied to vertex variables in other contexts.
addTags()is shown below. This query will add tags to person vertices to achieve the same effect as a base graph loading job example in the previous section.
LOADstatement has an optional clause for explicit tagging of loaded data. The tagging clause has two keywords,
TAGS(<tag_list>)specifies the tags to be set.
BYspecifies how to merge tags if the targeted vertex exists in the graph
BY OR:Add the given tags to the existing set of tags.
BY OVERWRITE:Replace the existing tags with the given ones.
personvertex data coming from a certain file. We have three files:
TAGSclause can specify a tag with a string literal (
"vip") so every vertex gets the same tag, or with a token reference by position (
$2) or by name (
quot;label") from the source file, so each vertex gets a data-dependent tag. If the tag clause refers to a non-existent tag, the loading job will still run, but the data will not be loaded at runtime. The loading job log will report these non-loaded vertices.
personvertices will automatically be tagged with
person:vip), then when one adds a vertex via the tag-based graph, the other tag-based graph may also see it.
vipNetonly includes vertices with the tag
vip. We can verify this by running a simple query to return all person vertices in
ACCESS_TAGprivileges can create, modify and drop tags, as well as create tag-based graphs for all graphs.
designerroles) can create/drop tags, and tag vertices. Users that have both the
designerroles) can create/drop tag-based graphs of the base graph.
ACCESS_TAGprivilege on the base graph are able to access the base graph as their roles allow, but they do not have access to the tags on the base graph. They cannot see whether any vertex type on the graph is taggable or if there are tag-based graphs of the base graph.
designerroles will inherit their base graph role on the tag-based graph. Additionally, the creator of the tag-based graph becomes an admin of the tag-based graph.
adminrole on a graph wants to grant a group of users access to a selective set of vertices.
Bto the target users.
T1. In the future, you also want the ability to give other users access to vertices based on the vertex class.
adminuser can do the following setup.
B, grant roles that have the appropriate privileges for the graph
Bto target users.
adminuser on a graph wants to give a group of users read/write access for a specific class of vertices. The users would be able to insert new vertices into the graph and query the data, and all the data they insert into the graph are tagged as the same class.
Bas if it is a normal graph. They can ingest new data, as well as operate on those vertices from the base graph that have the tag