DataGrip Overview, Part 10: SQL Files and DDL Data Sources
In a Nutshell
DataGrip's File Tools window lets you attach local folders and run SQL files with proper dialect/context so code completion and execution work. You can run multiple dump files via run configurations to recreate schemas and load data, and DataGrip surfaces errors for review. DDL Data Sources turn collections of SQL files into a browsable schema you can diff against real databases to manage schema changes through version control.
These notes were generated by AI and may contain inaccuracies.
The File Tools window is one of the most important tool windows in DataGrip. Opening it with the shortcut "command" and "two" makes it appear on the right side of the screen. The File Tools window displays work files from any folder on the local computer. To open a folder, or attach a folder to this window, use the button and select the needed folder.
For example, attaching a folder named "my scripts" makes its contents visible in the Files window. Opening the "queries.sql" file, which contains a simple "select" statement, triggers a notification that no SQL language is initialized for this file.
The dialect is set to PostgreSQL SQL, followed by specifying the context, data source, and schema. From that moment, the file understands the context. Writing code in this file enables code completion and all other software helper features to work. Running this query produces results.
Making changes to the file, such as adding a new query, causes a green bar to appear in the margin (the panel to the left of the text editor). This indicates differences between this version and the version in the version control system. Clicking on the green bar opens the Differences Viewer, which shows the changes.
Uploading (committing) changes is done through the Git interface in DataGrip. Both commit and commit-and-push operations are available for changes.
In addition to work files containing queries, dump files for various databases are present. For example, a folder for mySQL contains dump files. The "Sakila" file contains statements that create the object schema. The "Sakila data" file contains statements that insert the data into that new schema.
These files can be opened and run like regular files, but since they are large and managing them is not easy, the best way is to run them using boot settings. Selecting the two files, going to the context menu, and creating a boot configuration from this menu initiates the process. In the dialog window that opens, the order of these files is changed because creating the schema must come first. Selecting the target and pressing play executes all scripts from these files on the desired target.
Some errors may appear during execution, but DataGrip overcomes them. All errors can be reviewed after implementation is complete. To ensure the result is successful, verification confirms that the tables have been created and that the data is inside them.
DDL data sources are not actual data sources, but rather the structure of the database displayed in the Database Explorer. Information about the structure is stored in SQL files. In other words, DataGrip can visualize DDL schema files.
A collection of SQL files contains DDL statements. This is essentially a dump version of the Sakila scheme in PostgreSQL. Dragging them into the database explorer creates what is called a DDL data source, which represents the structure defined in those files. There is no data in this data source.
Clicking on a table navigates to the corresponding file.
DDL data sources are needed for several reasons. First, it is easier to understand what DDL files actually describe and to find potential errors in them. DDL data source graphs are also supported. Second, programming help is available when writing code without access to a real database. This applies more to using DataGrip functions as an add-on.
The most important benefit is the ability to compare the structure described in the DDL data source with the real structure. This helps use a state approach to keep the database in a version control system (VCS).
For example, a real database named real_db and a DDL data source named ddl_db are present. The DDL data source is based on files stored in Git. Therefore, pulling changes from the repository may reveal that the database structure has changed.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
