Getting Started
Last updated
Last updated
Your journey today starts on the internet. Open a web browser and navigate to https://hosted.doltdb.com. You should be greeted by this welcoming site (pun intended).
Click the "Sign In" button on the top right. A Sign In form will appear. Click the Create account tab.
Either use your Google account or use a valid email to create a Hosted Dolt account. Once you've chosen a username and clicked the Create Account button, use that account to Sign In. Once you sign in, your landing page will be an empty deployments page.
Now it's time to create a deployment. A deployment is a dedicated cloud host running the world's first and only version controlled SQL database, Dolt. This cloud host can be in Amazon Web Services (AWS) or Google Cloud Platform (GCP). This cloud host is monitored and backed up for you so you don't need to worry about operating it.
Start by clicking the "Create Deployment" button.
Give your deployment a name. I called mine getting-started
.
There are a few of options. You can safely leave the defaults except we're going to use the $50 trial instance and enable using Hosted Dolt as a remote endpoint. To switch to the trial instance, select t2.medium
from the instance type dropdown. To enable Hosted Dolt as a remote endpoint, select the "Use Web PKI Certificate" and "Expose remotesapi endpoint" options.
Click the "Create Deployment" button. Your deployment will go into "Starting" phase.
It will take a minute or two to launch your deployment. Our control plane is procuring an EC2 host, installing Dolt and all of our monitoring utilities on it, starting Dolt, and making the SQL endpoint visible to the internet.
Once the deployment completes your deployment page will look something like this. Note the connectivity information. This is the host, port, username, and password you use to connect to the deployed Dolt. You can make new usernames and passwords and delete this one, but you use this username and password to set up your database permissions. We won't cover that in this getting started but here's a helpful guide if you need it.
You now have a cloud deployed Dolt! Let's do something interesting with it.
Dolt is a version controlled SQL database. Let's make some tables to show off how to use it.
There are three ways to read or write from Hosted Dolt. You can:
Connect any MySQL-compatible client to it
Use the built-in SQL Workbench
Make a local clone
In this blog, we will show off (1) and (2) but we're going to start with the Workbench because it is the easiest to use.
Click on the Workbench tab of your deployment.
The workbench has writes off by default. We will turn those on and create a database. Click the "Enable writes" option and "Update" button at the bottom. Then, click the "+ Create database" link in the Available Databases box. I called my database "getting_started
. The workbench will immediately open once you create your database.
This should feel like a standard SQL workbench like Tableplus or Datagrip but it's web-based and has some extra Dolt-specific features like a Commit Log and Pull Requests.
Now let's create some tables using SQL. We're going to enter the following SQL queries into the query box. You have to run them one at a time.
I click the "Play" button to execute the queries. After running a query you are presented with a diff off the working set. You can start to see how Dolt's versioning capabilities make for a powerful workbench experience.
I finish up by subsequently running the last two create table queries.
Now time to use my first Dolt feature! I'm going to create a Dolt Commit. Make a Dolt commit when you want to preserve the state of the Dolt database permanently for future reference.
To make a Dolt Commit I click the Create Commit Button and am prompted to enter a commit message.
After clicking "Commit", I see that I've created a brand new commit hash.
I can also see my new commit in the Commit Log.
The built in Workbench in Hosted Dolt gives you a powerful web GUI to interact with Dolt. It has all the features of a workbench like Tableplus or Datagrip combined with features of GitHub like a commit log and Pull Requests. We'll be demoing Hosted Pull Requests later so keep reading.
Dolt is a multiplayer database. It works best when you have multiple editors collaborating.
I'm going to add Taylor as a collaborator. This will give Taylor permissions to see my deployment, use the workbench, and make a pull request.
Navigate out of the workbench and back to the deployment page by clicking the name of your deployment. In this case getting-started
in the breadcrumbs at the top of the workbench page. Click the "Settings" tab.
Click the "Add Collaborator" button, find the user you are looking for and select the permissions level you want to give him or her. In this case, I made Taylor an admin
.
Finish up by clicking the "Add Collaborator" button.
Taylor can now access the deployment page to get connectivity information. Her mission is to add rows to these new tables and make a Pull Request for me to review. Taylor actually did the next section as you can tell from the Hosted Dolt screenshots.
Dolt is a MySQL-compatible database. You can connect any client that can connect to MySQL to it. We're going to use the MySQl client that comes with MySQL in this section to connect to Dolt.
Head over to the MySQL Getting Started documentation and install MySQL on your machine. I used Homebrew to install MySQL on my Mac.
MySQL comes with a MySQL server called mysqld
and a MySQL client called mysql
. You're only interested in the client. After following the instructions from MySQL's documentation and opening a terminal, make sure you have a copy of the mysql client on your path:
Now, to connect the mysql client to Dolt, you need the host, port, username, and password from the Connectivity tab.
Then, in your terminal send in that information as arguments to mysql. The connectivity table even has a convenient section to copy/paste this information.
This MySQL client is connected to your Hosted Dolt instance. Any changes you make here will be visible to users of the workbench or any other client connected to the Hosted Dolt database.
So let's be safe and make our changes on a branch. A branch in Dolt is a lightweight way of isolating your changes from the "main" copy of the database. Since our goal is to make a Pull Request in the SQL Workbench, making a branch is necessary as pull requests are done between two branches, in this case "main" and our new branch.
In Dolt SQL, version control read operations are exposed as system tables or functions. Version control write operations are exposed as procedures.
If you are familiar with the Git command line, finding the appropriate system table, function, or procedure is easy. In our case, we want to create a branch called inserts
and switch to it to make our changes. We know in Git we can create a new branch with git checkout -b
or git branch
. Checkout will switch to that branch after Git creates it. This is a write operation so it must be a procedure in Dolt SQL. The convention in Dolt SQL is the Git equivalent commands are prefixed with dolt_
and arguments are passed in the command line fashion. So, in our case, we want to checkout a new branch called inserts
we run call dolt_checkout('-b', 'inserts');
. If you know Git and SQL, you already know how to use Dolt.
Great, Taylor is now on a new branch and can safely make her changes.
This is easy if you know SQL. In the MySQL client on the inserts
branch, Taylor ran the following SQL to add a few of the early employees here at DoltHub and assign them to teams.
Seems like it worked.
Finally, I have to make a Dolt commit to be able to merge my changes. I can do that by running call dolt_add()
and call dolt_commit()
.
Let's head back over to the workbench to make a Pull Request.
The Hosted Dolt workbench supports pull requests and human review of your Hosted Dolt database. Head back over to your browser with the Hosted Dolt Web UI up and go to the Workbench tab. Click the getting_started
database to open a workbench for it.
As you can see on the "main" branch there are no rows inserted in the tables.
But on the inserts branch there are!
We want to make a pull request from the inserts branch to the main branch, review our changes, and then merge inserts branch into the main branch if everything looks good. To do this we click the Pull Requests tab and click the "Create Pull Request" button.
Taylor selects the to branch as main and the from branch as inserts. She has the opportunity to add a name and description of the changes to help the reviewer figure out what I've done.
Finally, she clicks "Create pull request". She now sends me this Pull Request link for review.
On the Pull Request Page, I have access to a human readable diff of the changes under review.
Pull Requests give me the opportunity to have my database changes reviewed in the same way code is reviewed. I can click through the tables and make sure the changes are valid. I can add comments and discuss with my teammates. In this case, everything looks good so I will merge this pull request. On the Pull Request page, I click the green "Merge" button.
I head back over to the main branch and see Taylor's changes are now live.