Introduction
agtool is a program for performing a variety of operations on an AllegroGraph server or repository. Its general calling sequence for tools that operate on repositories is
% agtool <tool> [options] [REPO-SPEC] [arguments]
Some tools operate just on the running AllegroGraph server. The general for for such tools is
% agtool <tool> [--server SERVER_SPEC] [options] [arguments]
Most tools are documented in separate documents linked to from this document.
REPO SPECs
A repository specification or REPO SPEC argument identifies a repository and also contains the necessary SERVER SPEC information. The Repository Specification document describes the REPO SPEC format. In its concise form, a REPO SPEC encodes all the necessary information to identify a repository. Its general form is:
[USER:PASSWORD@][[HOST][:[PORT][s]]/][CATALOG:]REPO
The various elements are:
- The scheme
- Either
http
orhttps
. The default ishttp
. The scheme is encoded by the presence or absence of thes
following thePORT
:https
when thes
is persent,http
when it is not. - USER and PASSWORD
- A valid AllegroGraph user and that user's password.
- HOST
- The host on which the AllegroGraph server is running. The default is
127.0.0.1
, which is the same aslocalhost
. - PORT
- The port which the HOST is listening on. The default is 10035.
- CATALOG
- The name of the catalog which contains the specified REPOSITORY. Catalogs are defined in the configuration file and can only be created at server startup time so the specified CATALOG must already exist. If not specified, defaults to the root catalog.
- REPOSITORY
- The repository of interest. Depending on the tool, this repository may or may not exist (some tools create repositories).
In its simplest form, a REPO SPEC is just a repository name, which then expands to
localhost:10035/repository-name
If anything must have a value other than the default, more elements must be used. See Repository Specification for numerous examples.
So for example, to load an Ntriples file mydata.nt into the my-repository
repository, the command might be
% agtool load my-repository mydata.nt
or equivalently
% agtool load localhost:10035/my-repository mydata.nt
Tools that operate on repositories accept REPO SPECs for identifying repositories.
In earlier releases, most tools which acted on repositories had options --scheme
, --user
, --host
, --port
, and --catalog
(some of which had abbreviations). Some tools still accept these arguments. For those tools, use of these older arguments is deprecated and will signal a warning when used. If these arguments are accepted and used and a REPO-SPEC is also specified, values must be identical to what is specified in the REPO-SPEC argument.
SERVER SPECs
A SERVER SPEC specifies the running AllegroGraph server which the tool will operate on. If the tool operates on a repository, the SERVER SPEC information is included in the REPO SPEC which identifies the repository but some tools, like agtool user, do not operate on repositories.
A SERVER SPEC is typically the value of the --server
option (some tools use other option names to identify servers; replicate
, for example, uses --primary
and --secondary
). The option defaults to
--server http://127.0.0.1:10035
You must specify --server SERVER-SPEC
if any of the defaults do not apply.
A SERVER SPEC can be
HOSTNAME
HOSTNAME:PORT
SCHEME://[user:password@]HOSTNAME
SCHEME://[user:password@]HOSTNAME:PORT
Missing elements except for user
and password
are taken from the default above, so --server myhost
becomes --server http://myhost:10035
.
SCHEME
can be http
or https
.
Note that the SERVER SPEC does not use the same encoding as a concise REPO SPEC. In particular, the scheme cannot be specified by an s
after the port number as it can be in a concise REPO SPEC.
If the user who started the AllegroGraph server is executing agtool on the machine on which AllegroGraph server is running, agtool will then run under the same uid that the AllegroGraph server is running under. In that case for most tools, agtool acts as if it is being run by a superuser if no user and password are specified. This behavior is called OS authentication. It is common for production versions to be run this way, and it is also typical for users who are testing personal copies.
A superuser can generally run any agtool operation. Other users can run some, depending on their actual permissions. See Managing Users for information on user permissions.
Help
% agtool --help
displays a help string giving a brief description of each tool.
% agtool TOOL --help
displays a help string for the specific TOOL.
Tools
agtool can run the following tools. Use agtool TOOL --help to get more information on any tool.
- archive -- see Repository Backup and Restore
- cancel-purge-deleted-triples
- create-db
- define-attribute
- delete-attribute-definition
- delete-static-attribute-filter
- export -- see Repository Export
- get-metadata
- load -- see Data Import
- lookup-attribute-definitions
- materialize -- see Materializer
- memory-lock
- memory-unlock
- purge-deleted-triples
- purge-rate-limit
- query -- see Querying using agtool
- recover -- see Point-in-Time Recovery
- repl -- see Multi-master Replication
- replicate -- see Replication
- role -- see Managing Users
- shacl-validate -- see SHACL
- scheduler -- see Event Scheduler
- upgrade -- see the agtool upgrade program in the Repository Upgrading document.
- user -- see Managing Users
- version
- view-tlog
There are additional agtool tools that are not documented here. Some provide information useful for dealing with problem reports and user may be asked to run those as part of dealing with a problem report. Others are associated with other AllegroGraph features and should only be run as part of using those features. Those tools are documented with the feature rather than here.
Most agtool tools take the same options as the program they are replacing, but some have either new options or no longer accept previous options (usually the abbreviation is not accepted but the long form is). These changes are noted for each relevant tool.
Attribute and filter support
AllegroGraph supports triple attributes (key/value pairs associated with individual triples) and static filters (statements that can restrict access to triples based on their attribute values. These features are described in the Triple Attributes document.
Attributes can only be associated with a triple when the attribute has been defined. agtool can be used to define attributes (agtool define-attribute), delete attribute definitions (agtool delete-attribute-definition), lookup attribute definitions (agtool lookup-attribute-definitions), and set and delete a static attribute filter (agtool set-static-attribute-filter and agtool delete-static-attribute-filter). To see the calling sequence for these commands, execute
% agtool COMMAND --help
For example
% agtool define-attribute --help
The archive tool
Command calling template:
% agtool archive [options] command [command-args]
options are prefixed with double dashes (single dash in some cases) and may also take arguments. To get usage information, enter
% agtool archive --help
The commands which write to or read from files (backup, backup-all, backup-settings, restore, restore-all, and restore-settings) are passed a directory and perhaps additional information like a database name. The specific files are located and named within that directory following standard rules (described here. Unless the --supersede
option is specified to backup commands, the archive directory must either not exist or be empty.
agtool archive can be used to upgrade a database from the format on one AllegroGraph release to the format of a later release. This is the recommended way to upgrade since it provides a backup copy of the database in the earlier format which allows easy recovery if there are problems with the later version. The agtool upgrade tool does not (by itself) backup a database before upgrading.
See the Repository Backup and Restore document for a complete list of commands and options.
The materializer tool
Command calling template:
% agtool materialize [options] command [command-args]
See the Command Line Interface section in the Materializer document for details on the options.
The query tool
Command calling template:
% agtool query [options] REPO-SPEC [QUERY-FILE]*
See the Querying using agtool document for details on the arguments and options.
The export tool
Command calling template:
% agtool export [options] REPO-SPEC FILE
This will export the data in the repository identified by REPO-SPEC to FILE. For example,
% agtool export --output rdfxml user1:my-pw@agmachine/lesmis lesmis.rdf
exports the data in the lesmis repo (in the root catalog, since no catalog is specified) to the file lesmis.rdf. The format is rdfxml
. user1 must have read permission in lesmis.
See the Repository Export document for details on the options.
The load tool
The agtool load tool can be used to load data into a store from a file or a collection of files. See the Data Import document for details.
The tool calling template is:
% agtool load [options] REPO-SPEC SOURCE*
where REPO-SPEC identifies the repository into which the data should be loaded (the catalog can be specified as part of the REPO-SPEC, as can user and connection information). The SOURCEs are the file(s) to be loaded. The SOURCE can be standard input. Numerous options control the loading process. All are described in the Data Import document for details on the options.
agtool load can be run on the same machine as the AllegroGraph server by the same user who started the server, in which case no username or password is required, or on a different machine and/or by a different user, in which case the username and password of a user with AllegroGraph superuser privileges must be specified as part of the REPO-SPEC.
Here are a couple of examples of typical uses. In this first example, the user executing the command must be the user who started the AllegroGraph server and the command must be run on the same machine as the server:
% agtool load my-repository mydata.nt
Load the Ntriples file mydata.nt into the store my-repository in the root catalog. Since no port is specified, the port is the default, 10035.
In this example, the command is again run on the same machine as the Allegrograph server and by the user who started AllegroGraph. A non-default port is used.
% agtool load 10077/mycatalog:my-repo2 mydata-2.ttl mydata-3.ttl
Load the turtle format files mydata-2.ttl and mydata-3.ttl (the format determined by the file extensions) into the store my-repo2 in the catalog mycatalog. The server listening on port 10077.
Finally, a call from a different machine. Here the host running the server must be specified by name and the user and password must be provided:
% agtool load test:xyzzy@agmachine:10077/repo-7 mydata.ttl mydata.nq
Load the turtle format file mydata.ttl and an NQUAD format file mydata.nq (the format determined by the file extensions) into the store repo7 in the (default) root catalog. The server is running on the host agmachine and is listening on port 10077.
The recover tool
Command calling template:
% agtool recover [options] archive database
See the Point-in-Time Recovery document for details on the options and general usage.
The repl tool
The repl tool allows you to manage a multi-master replication cluster. See Using the agtool repl command in the Multi-master Replication document for more information.
A multi-master cluster should not be confused with single-master replication described below. Single-master replication allows for one master repository, where modifications (adding and deleting triples) can be made and replicas which cannot make modifications. Multi-master replication allows each replica to make modifications.
The replicate tool
The replication tool allows you to set up single-master replication where you have several identical instances of AllegroGraph running simultaneously, so if one fails one of the others can take over. The replicate command calling template is:
% agtool replicate [options]
See Replication Details document and also the Replication document for more information on agtool replicate and its options.
Single-master replication should not be confused with multi-master replication, described above.
The upgrade tool
agtool ugrade will do an in-place upgrade of a single database from an earlier release to the current release (the release containing the agtool being run). The upgrade is done without backing the database up. Backing up databases prior to upgrading is strongly recommended. See Repository Backup and Restore.
Command calling template:
% agtool upgrade GROUND-REPO-SPEC
A GROUND-REPO-SPEC specifies a single repository (not one that is federated or includes reasoning). See the agtool upgrade program in the Repository Upgrading document for further details. Be sure to backup any database before upgrading.
Managing users and roles
agtool user can be used to add and remove users and to set user permissions and access rights. agtool role can be used to create and manage roles. See Managing Users for information on managing users with *agtool and with AGWebView.
SHACL, the SHApe Constraint Language supported by AllegroGraph, can be used to verify that a set of triples meets various constraints. The validation is done by a call to agtool shacl-validate. See the SHACL document for more information.
The event scheduler tool
Users can schedule events to run scripts at specified times in the future. The scripts can be run once or repeated on a regular schedule. See the Event Scheduler document for more information. The utility for using agtool to schedule events is scheduler. The various commands are:
bin/agtool scheduler --help
Usage: agtool scheduler COMMAND [ OPTIONS ] ...
where COMMAND is one of:
* help - Display scheduler usage.
* delete-events - Delete events.
* log - Display the log of events
* events - List pending events.
* create-event - Create a new event.
To describe a particular command run:
agtool scheduler COMMAND --help