Comment on page
Procedures
Dolt provides native stored procedures to allow access to
dolt CLI commands from within a SQL session. Each procedure is named after the dolt command line command it matches, and takes arguments in an identical form.For example,
dolt checkout -b feature-branch is equivalent to executing the following SQL statement:CALL DOLT_CHECKOUT('-b', 'feature-branch');
SQL procedures are provided for all imperative CLI commands. For commands that inspect the state of the database and print some information, (
dolt diff, dolt log, etc.) system tables are provided instead.One important note: all procedures modify state only for the current session, not for all clients. So for example, whereas running
dolt checkout feature-branch will change the working HEAD for anyone who subsequently runs a command from the same dolt database directory, running CALL DOLT_CHECKOUT('feature-branch') only changes the working HEAD for that database session. The right way to think of this is that the command line environment is effectively a session, one that happens to be shared with whomever runs CLI commands from that directory.Adds working changes to staged for this session. Works exactly like
dolt add on the CLI, and takes the same arguments.After adding tables to the staged area, they can be committed with
DOLT_COMMIT().CALL DOLT_ADD('-A');
CALL DOLT_ADD('.');
CALL DOLT_ADD('table1', 'table2');
table: Table(s) to add to the list tables staged to be committed. The abbreviation '.' can be used to add all tables.-A: Stages all tables with changes.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Set the current database for the session
USE mydb;
-- Make modifications
UPDATE table
SET column = "new value"
WHERE pk = "key";
-- Stage all changes.
CALL DOLT_ADD('-A');
-- Commit the changes.
CALL DOLT_COMMIT('-m', 'committing all changes');
Sync with a configured backup. Other backup commands not supported via SQL yet.
CALL DOLT_BACKUP('sync', 'name');
+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Set the current database for the session
USE mydb;
-- Upload the current database contents to the named backup
CALL dolt_backup('sync', 'my-backup')
Create, delete, and rename branches.
To list branches, use the
DOLT_BRANCHES system table, instead of the DOLT_BRANCH() stored procedure.To look up the current branch, use the
@@<dbname>_head_ref system variable, or the active_branch() SQL function, as shown in the examples section below.WARNING: In a multi-session server environment, Dolt will prevent you from deleting or renaming a branch in use in another session. You can force renaming or deletion by passing the
--force option, but be aware that active clients on other sessions will no longer be able to execute statements after their active branch is removed and will need to end their session and reconnect.-- Create a new branch from the current HEAD
CALL DOLT_BRANCH('myNewBranch');
-- Create a new branch from start point of tip of feature1 branch.
CALL DOLT_BRANCH('myNewBranch', 'feature1');
-- Create a new branch by copying an existing branch
-- Will fail if feature1 branch already exists
CALL DOLT_BRANCH('-c', 'main', 'feature1');
-- Create or replace a branch by copying an existing branch
-- '-f' forces the copy, even if feature1 branch already exists
CALL DOLT_BRANCH('-c', '-f', 'main', 'feature1');
-- Delete a branch
CALL DOLT_BRANCH('-d', 'branchToDelete');
-- Rename a branch
CALL DOLT_BRANCH('-m', 'currentBranchName', 'newBranchName')
Branch names have a few restrictions which are similar to the constraints Git puts on branch names. Dolt's branches are a little more restrictive, as ASCII characters are required. Rules are as follows:
- All characters must be ASCII (7 Bit)
- May not start with '.' (period)
- May not contain '..' (two periods)
- May not contain '@{'
- May not contain ASCII control characters
- May not contain characters: ':', '?', '[', '\', '^', '~', '*'
- May not contain whitespace (spaces, tabs, newlines)
- May not end with '/'
- May not end with '.lock'
- May not be HEAD (case insensitive)
- May not be indistinguishable from a commit hash. 32 characters, where all characters are 0-9 or a-z (case sensitive)
The
dolt_branch() procedure implicitly commits the current transaction and begins a new one.-c, --copy: Create a copy of a branch. Must be followed by the name of the source branch to copy and the name of the new branch to create. Without the --force option, the copy will fail if the new branch already exists.-m, --move: Move/rename a branch. Must be followed by the current name of an existing branch and a new name for that branch. Without the --force option, renaming a branch in use on another server session will fail. Be aware that forcibly renaming or deleting a branch in use in another session will require that session to disconnect and reconnect before it can execute statements again.-d, --delete: Delete a branch. Must be followed by the name of an existing branch to delete. Without the --force option, deleting a branch in use on another server session will fail. Be aware that forcibly renaming or deleting a branch in use in another session will require that session to disconnect and reconnect before it can execute statements again.-f, --force: When used with the --copy option, allows for recreating a branch from another branch, even if the branch already exists. When used with the --move or --delete options, force will allow you to rename or delete branches in use in other active server sessions, but be aware that this will require those other sessions to disconnect and reconnect before they can execute statements again.-D: Shortcut for --delete --force.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- List the available branches
SELECT * FROM DOLT_BRANCHES;
+--------+----------------------------------+
| name | hash |
+--------+----------------------------------+
| backup | nsqtc86d54kafkuf0a24s4hqircvg68g |
| main | dvtsgnlg7n9squriob3nq6kve6gnhkf2 |
+--------+----------------------------------+
-- Create a new branch for development work from the tip of head and switch to it
CALL DOLT_BRANCH('myNewFeature');
CALL DOLT_CHECKOUT('myNewFeature');
-- View your current branch
select active_branch();
+----------------+
| active_branch |
+----------------+
| myNewFeature |
+----------------+
-- Create a new branch from an existing branch
CALL DOLT_BRANCH('-c', 'backup', 'bugfix-3482');
-- Rename a branch
CALL DOLT_BRANCH('-m', 'bugfix-3482', 'critical-bugfix-3482');
-- Delete a branch
CALL DOLT_BRANCH('-d', 'old-unused-branch');
Switches this session to a different branch.
With table names as arguments, restores those tables to their contents in the current HEAD.
Note, unlike the Git command-line, if you have a modified working set, those changes remain on the branch you modified after a
DOLT_CHECKOUT(). Uncommitted changes in the working set do not transfer to the checked out branch as on the command line. We modified this behavior in the SQL context because multiple users may be connected to the same branch. Having one user bring changes from various other branches with them when they switch branches is too disruptive in the multi-tenant SQL context.CALL DOLT_CHECKOUT('-b', 'my-new-branch');
CALL DOLT_CHECKOUT('my-existing-branch');
CALL DOLT_CHECKOUT('my-table');
DOLT_CHECKOUT() with a branch argument has two side effects on your session state:- 1.The session's current database, as returned by
SELECT DATABASE(), is now the unqualified database name. - 2.For the remainder of this session, references to the unqualified name of this database will resolve to the branch checked out.
See the comments after the statements below for an example of this behavior, and also read Using Branches
set autocommit = on;
use mydb/branch1; -- current db is now `mydb/branch1`
insert into t1 values (1); -- modifying the `branch1` branch
call dolt_checkout('branch2'); -- current db is now `mydb`
insert into t1 values (2); -- modifying the `branch2` branch
use mydb/branch3; -- current db is now `mydb/branch3`
insert into mydb.t1 values (3); -- modifying the `branch2` branch
-b: Create a new branch with the given name.+---------+------+-----------------------------+
| Field | Type | Description |
+---------+------+-----------------------------+
| status | int | 0 if successful, 1 if not |
| message | text | success/failure information |
+---------+------+-----------------------------+
-- Set the current database for the session
USE mydb;
-- Create and checkout to a new branch.
CALL DOLT_CHECKOUT('-b', 'feature-branch');
-- Make modifications
UPDATE table
SET column = "new value"
WHERE pk = "key";
-- Stage and commit all changes.
CALL DOLT_COMMIT('-a', '-m', 'committing all changes');
-- Go back to main
CALL DOLT_CHECKOUT('main');
Apply the changes introduced by an existing commit.
Apply changes from existing commit and creates a new commit from the current HEAD.
CALL DOLT_CHERRY_PICK('my-existing-branch~2');
CALL DOLT_CHERRY_PICK('qj6ouhjvtrnp1rgbvajaohmthoru2772');
No options for this procedure.
+-----------------------+------+---------------------------------+
| Field | Type | Description |
+-----------------------+------+---------------------------------+
| hash | text | hash of the applied commit |
| data_conflicts | int | number of data conflicts |
| schema_conflicts | int | number of schema conflicts |
| constraint_violations | int | number of constraint violations |
+-----------------------+------+---------------------------------+
For the below example consider the following set up of
main and mybranch branches:-- Checkout main branch
CALL DOLT_CHECKOUT('main');
-- View a log of commits
SELECT commit_hash, message FROM dolt_log;
+----------------------------------+----------------------------+
| commit_hash | message |
+----------------------------------+----------------------------+
| 7e2q0hibo2m2af874i4e7isgnum74j4m | create a new table |
| omuqq67att6vfnka94drdallu4983gnr | Initialize data repository |
+----------------------------------+----------------------------+
2 rows in set (0.00 sec)
-- View the table
SELECT * FROM mytable;
Empty set (0.00 sec)
-- Checkout new branch
CALL DOLT_CHECKOUT('mybranch');
-- View a log of commits
SELECT commit_hash, message FROM dolt_log;
+----------------------------------+----------------------------+
| commit_hash | message |
+----------------------------------+----------------------------+
| 577isdjbq1951k2q4dqhli06jlauo51p | add 3, 4, 5 to the table |
| k318tpmqn4l97ofpaerato9c3m70lc14 | add 1, 2 to the table |
| 7e2q0hibo2m2af874i4e7isgnum74j4m | create a new table |
| omuqq67att6vfnka94drdallu4983gnr | Initialize data repository |
+----------------------------------+----------------------------+
4 rows in set (0.00 sec)
-- View the table
SELECT * FROM mytable;
+---+
| a |
+---+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+---+
5 rows in set (0.00 sec)
We want to cherry-pick only the change introduced in commit hash
'k318tpmqn4l97ofpaerato9c3m70lc14', which inserts 1 and 2 to the table. Specifying 'mybranch~1' instead of the commit hash also works.-- Checkout main branch
CALL DOLT_CHECKOUT('main');
-- Cherry-pick the commit
CALL DOLT_CHERRY_PICK('k318tpmqn4l97ofpaerato9c3m70lc14');
+----------------------------------+
| hash |
+----------------------------------+
| mh518gdgbsut8m705b7b5rie9neq9uaj |
+----------------------------------+
1 row in set (0.02 sec)
mydb> SELECT * FROM mytable;
+---+
| a |
+---+
| 1 |
| 2 |
+---+
2 rows in set (0.00 sec)
mydb> SELECT commit_hash, message FROM dolt_log;
+----------------------------------+----------------------------+
| commit_hash | message |
+----------------------------------+----------------------------+
| mh518gdgbsut8m705b7b5rie9neq9uaj | add 1, 2 to the table |
| 7e2q0hibo2m2af874i4e7isgnum74j4m | create a new table |
| omuqq67att6vfnka94drdallu4983gnr | Initialize data repository |
+----------------------------------+----------------------------+
3 rows in set (0.00 sec)
Deletes untracked tables in the working set.
Deletes only specified untracked tables if table names passed as arguments.
With
--dry-run flag, tests whether removing untracked tables will return with zero status.CALL DOLT_CLEAN();
CALL DOLT_CLEAN('untracked-table');
CALL DOLT_CLEAN('--dry-run');
--dry-run: Test removing untracked tables from working set.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Create three new tables
create table tracked (x int primary key);
create table committed (x int primary key);
create table untracked (x int primary key);
-- Commit the first table
call dolt_add('committed');
call dolt_commit('-m', 'commit a table');
+----------------------------------+
| hash |
+----------------------------------+
| n7gle7jv6aqf72stbdicees6iduhuoo9 |
+----------------------------------+
-- Track the second table
call dolt_add('tracked');
-- Observe database status
select * from dolt_status;
+------------+--------+-----------+
| table_name | staged | status |
+------------+--------+-----------+
| tracked | true | new table |
| untracked | false | new table |
+------------+--------+-----------+
-- Clear untracked tables
call dolt_clean('untracked');
-- Observe final status
select * from dolt_status;
+------------+--------+-----------+
| table_name | staged | status |
+------------+--------+-----------+
| tracked | true | new table |
+------------+--------+-----------+
-- Committed and tracked tables are preserved
show tables;
+----------------+
| Tables_in_tmp3 |
+----------------+
| committed |
| tracked |
+----------------+
Clones an existing Dolt database into a new database within the current Dolt environment. The existing database must be specified as an argument, either as a file URL that points to an existing Dolt database on disk, or a
doltremote URL for remote hosted database (e.g. a database hosted on DoltHub or DoltLab), or a <org>/<database> (e.g. dolthub/us-jails) as a shorthand for a database hosted on DoltHub. An additional argument can optionally be supplied to specify the name of the new, cloned database, otherwise the current name of the existing database will be used.NOTE: When cloning from a file URL, you must currently include the
.dolt/noms subdirectories. For more details see the GitHub tracking issue, dolt#1860.CALL DOLT_CLONE('file:///myDatabasesDir/database/.dolt/noms');
CALL DOLT_CLONE('dolthub/us-jails', 'myCustomDbName');
--remote: Name of the remote to be added to the new, cloned database. The default is 'origin'.-b, --branch: The branch to be cloned. If not specified all branches will be cloned.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Clone the dolthub/us-jails database from DoltHub using the <org>/<database> notation.
CALL DOLT_CLONE('dolthub/us-jails');
-- Use the new, cloned database
-- NOTE: backticks are required for database names with hyphens
USE `us-jails`;
SHOW TABLES;
+-----------------------------+
| Tables_in_us-jails |
+-----------------------------+
| incidents |
| inmate_population_snapshots |
| jails |
+-----------------------------+
-- Clone the dolthub/museum-collections database, this time using a doltremoteapi URL, cloning
-- only a single branch, customizing the remote name, and providing a custom database name.
CALL DOLT_CLONE('-branch', 'prod', '-remote', 'dolthub',
'https://doltremoteapi.dolthub.com/dolthub/ge-taxi-demo', 'taxis');
-- Verify that only the prod branch was cloned
USE taxis;
SELECT * FROM DOLT_BRANCHES;
+------+----------------------------------+------------------+------------------------+-------------------------+------------------------------+
| name | hash | latest_committer | latest_committer_email | latest_commit_date | latest_commit_message |
+------+----------------------------------+------------------+------------------------+-------------------------+------------------------------+
| prod | 1s61u4rbbd26u0tlpdhb46cuejd1dogj | oscarbatori | oscarbatori@gmail.com | 2021-06-14 17:52:58.702 | Added first cut of trip data |
+------+----------------------------------+------------------+------------------------+-------------------------+------------------------------+
-- Verify that the default remote for this new, cloned database is named "dolthub" (not "origin")
SELECT * FROM DOLT_REMOTES;
+---------+--------------------------------------------------------+-----------------------------------------+--------+
| name | url | fetch_specs | params |
+---------+--------------------------------------------------------+-----------------------------------------+--------+
| dolthub | https://doltremoteapi.dolthub.com/dolthub/ge-taxi-demo | ["refs/heads/*:refs/remotes/dolthub/*"] | {} |
+---------+--------------------------------------------------------+-----------------------------------------+--------+
Commits staged tables to HEAD. Works exactly like
dolt commit with each value directly following the flag.DOLT_COMMIT() also commits the current transaction.CALL DOLT_COMMIT('-a', '-m', 'This is a commit');
CALL DOLT_COMMIT('-m', 'This is a commit');
CALL DOLT_COMMIT('-m', 'This is a commit', '--author', 'John Doe <[email protected]>');
-m, --message: Use the given <msg> as the commit message. Required-a, --all: Stages all modified tables (but not newly created tables) before committing.-A, --ALL: Stages all tables (including new tables) before committing.--allow-empty: Allow recording a commit that has the exact same data as its sole parent. This is usually a mistake, so it is disabled by default. This option bypasses that safety.--skip-empty: Record a commit only if there are changes to be committed. The commit operation will be a no-op, instead of an error, if there are no changes staged to commit. An error will be thrown if --skip-empty is used with --allow-empty.--date: Specify the date used in the commit. If not specified the current system time is used.--author: Specify an explicit author using the standard "A U Thor [email protected]" format.+-------+------+----------------------------+
| Field | Type | Description |
+-------+------+----------------------------+
| hash | text | hash of the commit created |
+-------+------+----------------------------+
-- Set the current database for the session
USE mydb;
-- Make modifications
UPDATE table
SET column = "new value"
WHERE pk = "key";
-- Stage all changes and commit.
CALL DOLT_COMMIT('-a', '-m', 'This is a commit', '--author', 'John Doe <[email protected]>');
When a merge finds conflicting changes, it documents them in the dolt_conflicts table. A conflict is between two versions: ours (the rows at the destination branch head) and theirs (the rows at the source branch head).
dolt conflicts resolve will automatically resolve the conflicts by taking either the ours or theirs versions for each row.CALL DOLT_CONFLICTS_RESOLVE('--ours', <table>);
CALL DOLT_CONFLICTS_RESOLVE('--theirs', <table>);
<table>: List of tables to be resolved. '.' can be used to resolve all tables.--ours: For all conflicts, take the version from our branch and resolve the conflict.--theirs: For all conflicts, take the version from their branch and resolve the conflict.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Set the current database for the session
USE mydb;
-- Attempt merge
CALL DOLT_MERGE('feature-branch');
-- Check for conflicts
SELECT * FROM dolt_conflicts;
-- Resolve conflicts for tables t1 and t2 with rows from our branch.
CALL DOLT_CONFLICTS_RESOLVE('--ours', 't1', 't2');
Fetch refs, along with the objects necessary to complete their histories and update remote-tracking branches. Works exactly like
dolt fetch on the CLI, and takes the same arguments.CALL DOLT_FETCH('origin', 'main');
CALL DOLT_FETCH('origin', 'feature-branch');
CALL DOLT_FETCH('origin', 'refs/heads/main:refs/remotes/origin/main');
No options for this procedure.
+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Get remote main
CALL DOLT_FETCH('origin', 'main');
-- Inspect the hash of the fetched remote branch
SELECT HASHOF('origin/main');
-- Merge remote main with current branch
CALL DOLT_MERGE('origin/main');
Cleans up unreferenced data from the database. Running the
dolt_gc procedure on a Dolt sql-server will block all writes while garbage collection is in progress.CALL DOLT_GC();
CALL DOLT_GC('--shallow');
--shallow Performs a faster but less thorough garbage collection.+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
To prevent concurrent writes potentially referencing garbage collected chunks, running
call dolt_gc() will break all open connections to the running server. In flight queries on those connections may fail and must be retried. Re-establishing connections after they are broken is safe.At the end of the run, the connection which ran call dolt_gc() will be left open in order to deliver the results of the operation itself. The connection will be left in a terminally broken state where any attempt to run a query on it will result in the following error:
ERROR 1105 (HY000): this connection was established when this server performed an online
garbage collection. this connection can no longer be used. please reconnect.
The connection should be closed. In some connection pools it can be awkward to cause a single connection to actually close. If you need to run call dolt_gc() programmatically, one work around is to use a separate connection pool with a size of 1 which can be closed after the run is successful.
Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch. Works exactly like
dolt merge on the CLI, and takes the same arguments.Any resulting merge conflicts must be resolved before the transaction can be committed or a new Dolt commit created.
DOLT_MERGE() creates a new commit for any successful merge with auto-generated commit message if not defined.CALL DOLT_MERGE('feature-branch'); -- Optional --squash parameter
CALL DOLT_MERGE('feature-branch', '--no-ff', '-m', 'This is a msg for a non fast forward merge');
CALL DOLT_MERGE('--abort');
--no-ff: Create a merge commit even when the merge resolves as a fast-forward.--squash: Merges changes to the working set without updating the commit history-m <msg>, --message=<msg>: Use the given as the commit message. This is only useful for --non-ff commits.--abort: Abort the current conflict resolution process, and try to reconstruct the pre-merge state.--author: Specify an explicit author using the standard A U Thor <[email protected]> format.When merging a branch, your session state must be clean.
COMMIT orROLLBACK any changes, then DOLT_COMMIT() to create a new dolt commit on the target branch.If the merge causes conflicts or constraint violations, you must resolve them using the
dolt_conflicts system tables before the transaction can be committed. See Dolt system tables for details.+--------------+------+--------------------------------------+
| Field | Type | Description |
+--------------+------+--------------------------------------+
| hash | text | hash of the merge commit |
| fast_forward | int | whether the merge was a fast forward |
| conflicts | int | number of conflicts created |
+--------------+------+--------------------------------------+
-- Set the current database for the session
USE mydb;
-- Create and checkout to a new branch.
CALL DOLT_CHECKOUT('-b', 'feature-branch');
-- Make modifications
UPDATE table
SET column = "new value"
WHERE pk = "key";
-- Stage and commit all changes.
CALL DOLT_COMMIT('-a', '-m', 'committing all changes');
-- Go back to main
CALL DOLT_MERGE('feature-branch', '--author', 'John Doe <[email protected]>');
Fetch from and integrate with another database or a local branch. In its default mode,
dolt pull is shorthand for dolt fetch followed by dolt merge <remote>/<branch>. Works exactly like dolt pull on the CLI, and takes the same arguments.Any resulting merge conflicts must be resolved before the transaction can be committed or a new Dolt commit created.
CALL DOLT_PULL('origin');
CALL DOLT_PULL('origin', 'some-branch');
CALL DOLT_PULL('feature-branch', '--force');
--no-ff: Create a merge commit even when the merge resolves as a fast-forward.--squash: Merges changes to the working set without updating the commit history--force: Ignores any foreign key warnings and proceeds with the commit.When merging a branch, your session state must be clean.
COMMIT orROLLBACK any changes, then DOLT_COMMIT() to create a new dolt commit on the target branch.If the merge causes conflicts or constraint violations, you must resolve them using the
dolt_conflicts system tables before the transaction can be committed. See Dolt system tables for details.+--------------+------+-------------------------------------+
| Field | Type | Description |
+--------------+------+-------------------------------------+
| fast_forward | int | whether the pull was a fast forward |
| conflicts | int | number of conflicts created |
+--------------+------+-------------------------------------+
-- Update local working set with remote changes
-- Note: this requires upstream tracking information to be set in order for
-- Dolt to know what remote branch to merge
CALL DOLT_PULL('origin');
-- Update local working set with remote changes from an explicit branch
CALL DOLT_PULL('origin', 'some-branch');
-- View a log of new commits
SELECT * FROM dolt_log LIMIT 5;
Permanently deletes any dropped databases that are being held in a temporary holding area. When a Dolt database is dropped, it is moved to a temporary holding area where the
dolt_undrop() stored procedure can restore it. The dolt_purge_dropped_databases() stored procedure clears this holding area and permanently deletes any data from those databases. This action is not reversible, so callers should be cautious about using it. The main benefit of using this function is to reclaim disk space used by the temporary holding area. Because this is a destructive operation, callers must have SUPER privileges in order to execute it.-- Create a database and populate a table in the working set
CREATE DATABASE database1;
use database1;
create table t(pk int primary key);
-- Dropping the database will move it to a temporary holding area
DROP DATABASE database1;
-- At this point, the database can be restored by calling dolt_undrop('database1'), but
-- instead, we permanently delete it by calling dolt_purge_dropped_databases().
CALL dolt_purge_dropped_databases();
Updates remote refs using local refs, while sending objects necessary to complete the given refs. Works exactly like
dolt push on the CLI, and takes the same arguments.CALL DOLT_PUSH('origin', 'main');
CALL DOLT_PUSH('--force', 'origin', 'main');
--force: Update the remote with local history, overwriting any conflicting history in the remote.+---------+------+-----------------------------+
| Field | Type | Description |
+---------+------+-----------------------------+
| status | int | 0 if successful, 1 if not |
| message | text | success/failure information |
+---------+------+-----------------------------+
-- Checkout new branch
CALL DOLT_CHECKOUT('-b', 'feature-branch');
-- Add a table
CREATE TABLE test (a int primary key);
-- Create commit
CALL DOLT_COMMIT('-a', '-m', 'create table test');
-- Push to remote
CALL DOLT_PUSH('origin', 'feature-branch');
Adds a remote for a database at given url, or removes an existing remote with its remote-tracking branches and configuration settings. Similar to
dolt remote command on the CLI, with the exception of cloud provider flags. To list existing remotes, use the dolt_remotes system table.CALL DOLT_REMOTE('add','remote_name','remote_url');
CALL DOLT_REMOTE('remove','existing_remote_name');
+--------+------+---------------------------+
| Field | Type | Description |
+--------+------+---------------------------+
| status | int | 0 if successful, 1 if not |
+--------+------+---------------------------+
-- Add a HTTP remote
CALL DOLT_REMOTE('add','origin','https://doltremoteapi.dolthub.com/Dolthub/museum-collections');
-- Add a HTTP remote with shorthand notation for the URL
CALL DOLT_REMOTE('add','origin1','Dolthub/museum-collections');
-- Add a filesystem based remote
CALL DOLT_REMOTE('add','origin2','file:///Users/jennifer/datasets/museum-collections');
-- List remotes to check.
SELECT * FROM dolt_remotes;
+---------+--------------------------------------------------------------+-----------------------------------------+--------+
| name | url | fetch_specs | params |
+---------+--------------------------------------------------------------+-----------------------------------------+--------+
| origin | https://doltremoteapi.dolthub.com/Dolthub/museum-collections | ["refs/heads/*:refs/remotes/origin/*"] | {} |
| origin1 | https://doltremoteapi.dolthub.com/Dolthub/museum-collections | ["refs/heads/*:refs/remotes/origin1/*"] | {} |
| origin2 | file:///Users/jennifer/datasets/museum-collections | ["refs/heads/*:refs/remotes/origin2/*"] | {} |
+---------+--------------------------------------------------------------+-----------------------------------------+--------+
-- Remove a remote
CALL DOLT_REMOTE('remove','origin1');
-- List remotes to check.
SELECT * FROM dolt_remotes;
+---------+--------------------------------------------------------------+-----------------------------------------+--------+
| name | url | fetch_specs | params |