~/dolt
.getting_started
will be created here once you run create database getting_started
. Navigating to ~/dolt/getting_started
will allow you to access this database using the Dolt command line.dolt sql-server
. Running this command starts the server on port 3306.dolt sql-server
, you'll see the following log line.mysqld
and a MySQL client called mysql
. You're only interested in the client. After following the instructions from MySQL's documentation, make sure you have a copy of the mysql
client on your path:mysql
client to Dolt, you have to force the MySQL client through the TCP interface by passing in a host and port. The default is the socket interface which Dolt does not support. The MySQL client also requires you specify a user, in this case root
.dolt sql-server
terminalmysql
client and execute the following SQL statements to create a database called getting_started
. The getting_started
database will have three tables: employees
, teams
, and employees_teams
.dolt_<command>
pattern. So dolt add
on the CLI becomes dolt_add
as a stored procedure. Passing options also follows the command line model. For instance, to specify tables to add, send the table names in as options to the dolt_add
procedure. For named arguments like sending a message into the dolt_commit
command use two arguments in sequence like ('-m', 'This is a message')
. If you know Git, the version control procedures and system tables should feel familiar.dolt_log
system table.COMMIT
. In this case, I am running the database with AUTOCOMMIT
on, so each SQL statement is automatically generating a transaction COMMIT
. If you want system to generate a Dolt commit for every transaction use the system variable,@@dolt_transaction_commit
.JOIN
. Dolt supports up to twelve table JOIN
s. Again, Dolt is a modern SQL relational database paired with Git-style version control.dolt_status
and dolt_diff_<tablename>
system tables.employees
table. The values were previously NULL
and now they are populated.-am
.dolt_log
and see which tables changed in each commit using an unscoped dolt_diff
. Unscoped dolt_diff
tells you whether schema, data, or both changed in that particular commit for the table.call dolt_reset()
. Let's imagine I accidentally drop a table.dolt_revert()
.drop database
. This deletes the database and all of it's history on disk. drop database
works this way for SQL tool compatibility as it is common for import tools to issue a drop database
to clear all database state before an import. Dolt implements remotes like in Git so you can maintain an offline copy for backup using clone, fetch, push, and pull. Maintaining a remote copy allows you to restore in the case of an errant drop database
query.getting_started
as your database, and root
as your user.dolt_checkout()
stored procedure. Using the -b
option creates a branch, just like in Git.as of
syntax.dolt_diff()
table function. It takes the table name and two branches as arguments.start_date
column on a new branch and populate it.schema_changes
branch and data on the modifications
branch completed flawlessly. It's time to merge all our edits together onto main
. This is done using the dolt_merge
stored procedure.dolt_history_<tablename>
and dolt_diff_<tablename>
to explore the lineage features in Dolt.dolt_history_<tablename>
shows you the state of the row at every commit.dolt_diff_<tablename>
allows you to filter the history down to only commits when the cell in question changed. In this case, I'm interested in the commits that are changing my first name. Note, there are two commits that changed my name because one is the original change and the second is the merge commit.