|
| 1 | +--- |
| 2 | +id: getting-started-management-ui |
| 3 | +title: Using the Management UI |
| 4 | +slug: /cli/getting-started/using-the-management-ui |
| 5 | +--- |
| 6 | + |
| 7 | +### Using the Management UI |
| 8 | +Aside from being a command line tool, Atlas also has a user interface that allows us to visually manage our schemas. |
| 9 | + |
| 10 | +After being introduced to the CLI’s capabilities, let’s see what we can do with the Management UI. |
| 11 | + |
| 12 | +###Inspecting |
| 13 | +We will start off by inspecting our database with the `-w` flag. To do so, run: |
| 14 | + |
| 15 | +`atlas schema inspect -d "mysql://root:pass@tcp(localhost:3306)/example" -w` |
| 16 | + |
| 17 | +Our browser will open automatically, and we should see a similar output in the CLI: |
| 18 | +``` |
| 19 | +Atlas UI available at: http://127.0.0.1:5800/projects/25769803777/schemas/1 |
| 20 | +Press Ctrl+C to stop |
| 21 | +``` |
| 22 | + |
| 23 | +When the UI opens, we are taken to the schema page. This screen displays a high-level view of our Atlas schema. |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | + |
| 28 | +On the top-left (1) we can see a box with information about our schema. The "Activity & History" panel (2) holds an audit history for all changes made to the schema. Each log is clickable, allowing us to view the diff between the schema and its previous state. On the bottom-right (3), the schema is described using the Atlas DDL. On the bottom-left part of the screen (4), the UI displays an ERD (Entity-relation diagram) showing the different tables and the connections between them (via foreign-keys). By clicking the "expand" icon on the top-right corner of the ERD panel, we can open a more detailed view of our schema. |
| 29 | + |
| 30 | + |
| 31 | + |
| 32 | +### Running a migration |
| 33 | + |
| 34 | +Now that we have seen how Atlas can visualize our database schema in the UI, let’s see how to initiate a migration. |
| 35 | + |
| 36 | +First, we will make changes to our schema by clicking on the "Edit Schema" button on the top right-hand corner. |
| 37 | + |
| 38 | + |
| 39 | + |
| 40 | +Next, add the table `likes` to the schema: |
| 41 | +``` |
| 42 | +table "likes" { |
| 43 | + schema = schema.example |
| 44 | + column "id" { |
| 45 | + null = false |
| 46 | + type = int |
| 47 | + } |
| 48 | + column "user_id" { |
| 49 | + null = false |
| 50 | + type = int |
| 51 | + } |
| 52 | + column "blog_post_id" { |
| 53 | + null = false |
| 54 | + type = int |
| 55 | + } |
| 56 | + primary_key { |
| 57 | + columns = [table.likes.column.id] |
| 58 | + } |
| 59 | + foreign_key "like_blog_post" { |
| 60 | + columns = [table.likes.column.blog_post_id] |
| 61 | + ref_columns = [table.blog_posts.column.id] |
| 62 | + on_update = "RESTRICT" |
| 63 | + on_delete = "RESTRICT" |
| 64 | + } |
| 65 | + foreign_key "like_user" { |
| 66 | + columns = [table.likes.column.user_id] |
| 67 | + ref_columns = [table.users.column.id] |
| 68 | + on_update = "RESTRICT" |
| 69 | + on_delete = "RESTRICT" |
| 70 | + } |
| 71 | + index "like_blog_post" { |
| 72 | + columns = [table.likes.column.blog_post_id] |
| 73 | + } |
| 74 | + index "like_user" { |
| 75 | + columns = [table.likes.column.user_id] |
| 76 | + } |
| 77 | +} |
| 78 | +``` |
| 79 | + |
| 80 | +Click "save" on the top right-hand corner. |
| 81 | + |
| 82 | + |
| 83 | + |
| 84 | +Going back to our schema page, we can notice a few changes. First, our schema is now out of sync. This means we have created a change in the desired state that isn't yet reflected in the database. When a schema is out of sync, two separate schemas appear: desired and inspected. |
| 85 | +The _desired_ schema is the one being edited in the UI. The _inspected_ schema is the |
| 86 | +true, current state of the database. By clicking the toggle and changing the view to "unified", the schema is shown as one with a highlighted diff. |
| 87 | + |
| 88 | +Looking at the ERD, we can see that our table `likes` is green and has a plus-sign (+) next to it, showing that it needs to be added. This means the change has been recorded, but not yet applied. |
| 89 | + |
| 90 | + |
| 91 | + |
| 92 | +Now, let’s run a migration! |
| 93 | +Click "Migrate Schema" in the Schema Status box to apply the changes we want to make to our schema. |
| 94 | + |
| 95 | +The migration screen will open up, running the setup automatically. After the setup succeeds, we will see the migration plan. |
| 96 | +The diff in the schema in HCL on the left pane, and the planned SQL statements on the right. |
| 97 | + |
| 98 | + |
| 99 | + |
| 100 | +To start the migration, click "Apply". If you ever wish to not go through with a migration, you can click "Abort". |
| 101 | + |
| 102 | + |
| 103 | + |
| 104 | +Congrats, we have successfully completed a migration! |
| 105 | + |
| 106 | +As expected, after executing our migration plan, our database and desired schema are now synced. |
| 107 | + |
| 108 | + |
| 109 | + |
| 110 | +### Conclusion |
| 111 | +In this section we learned how to use the Management UI to inspect our database and run migrations. |
0 commit comments