Tutorials

在 DataGrip 中处理源代码

基础知识

对象的源代码是创建该对象所需的 DDL 脚本的核心部分。 也就是说,CREATE 语句不是对象源代码的一部分。 源代码存储在数据库中。 源代码中最常见的对象是视图、函数和存储的过程。

在许多其他工具中,更新源代码前,首先需要生成 CREATE OR REPLACE 脚本,做出所需的变更,然后再运行。 在 DataGrip 中,其工作方式略有不同。 完成变更后,就会生成正确的脚本。

来自其他工具的使用者通常会犯这样的错误:打开 DDL,复制,修改,调整 CREATE 语句(通常添加 OR REPLACE 部分),然后运行新脚本。 这不是更新源代码的正确方式

加载源

无论是什么样的数据源,DataGrip 都会执行“内省”过程 – IDE 会提前检索对象的所有元数据。 这意味着在执行内省时加载所有源代码。

您可以在数据源属性的 Load Sources for(加载源)选项中选择所需的值来管理此过程。

在 Oracle 中,可以选择较低的内省级别来不加载源:

您可能会问:如果源代码在执行内省时加载,是否意味着它们已经过时了?

是的。 教程后面的部分将说明如何处理这种情况。

双击数据库资源管理器中的对象或在 SQL 脚本中按 Cmd/Ctrl+B 可以打开 DDL 编辑器。 在数据库资源管理器中双击视图会打开数据:要打开 DDL 资源管理器,请点击工具栏中的 DDL 按钮。

这将打开 DDL 编辑器。 在这里,您可以找到对象的 CREATE 脚本。

重要提示 !生成的脚本中的对象引用是非限定的,换句话说,使用的是 %view_name% 而不是 %schema_name%.%view_name%。 这是为了能够复制脚本以在另一个上下文中应用。 如果您想要一个带有限定引用的脚本,请使用 SQL 生成器

在 DDL 编辑器中,您可以更改源代码。 编辑对象的源代码时,DataGrip 会跟踪变更并在间距中高亮显示。

例如,向过程或函数添加注释行。 添加的行会高亮显示。 点击间距中高亮显示的行,会显示带有 Show Diff (显示差异)按钮的小工具栏。 点击 Show Diff(显示差异)按钮即可查看添加的代码与源代码之间的差异。

完成变更后,点击 Submit(提交)按钮。

DataGrip 将生成修改脚本并显示预览。

如果您对结果满意,请点击 OK(确定),脚本随后会在数据库中执行。 因此,所需的源代码将被更改。

DataGrip 不仅在创建脚本中添加 OR REPLACE,还可以处理更困难的情况,包括更改对象的签名或对象重命名。 需要时,将创建 DROP 和 CREATE 脚本。

一次更改多个对象

在 DDL 编辑器中完成变更但尚未提交时,DataGrip 会将其存储,直到提交。 例如,如果您更改了多个对象,则会缓存多个更改的 DDL,等待应用。 在 Database Changes(数据库变更)工具窗口中,您可以观察所有待处理源代码变更并一次全部提交。

过时的缓存对象

如前所述,DataGrip 会缓存在内省时加载的源代码。 如果打开的对象更新自第三方位置,通知将显示缓存对象与数据库中同一对象的源代码不同。

如果您在 IDE 中看到此警告,您可以选择以下操作:

  • Synchronize(同步):从数据库获取变更并更新缓存的本地对象。
  • Disable check(禁用检查):禁用此通知。

此外,对象源代码版本与数据库中的版本之间可能存在冲突。 例如,与其他人修改了相同的源代码并点击 Submit(提交)的情况。

您可以使用 Force Refactoring(强制重构)强制替换数据库中对象的源代码,也可以同步对象状态,然后点击 Abort Refactoring and Synchronize(中止重构并同步)保留变更并继续。

选择 Abort Refactoring and Synchronize(中止重构并同步)后,DataGrip 将中止提交操作并从数据库获取变更,就像点击 Synchronize(同步)一样。 如果冲突仍然存在,您将看到以下通知。

在此通知中,您可以选择以下选项:

  • Revert local changes(还原本地变更):回滚所有变更并将其替换为数据库中的版本。
  • Keep local changes(保留本地变更):使用您的变更并覆盖数据库中的变更。
  • Merge(合并):显示差异对话框,合并对象源代码的版本。

本地历史记录

您对源代码所做的所有变更都存储在本地。 如果您想在最新更新之前及时返回并检查函数的源代码,您可以使用 Local History(本地历史记录)。

Local History(本地历史记录)中的修订包含所有本地变更,还包括内省期间从数据库检索的版本。 因此,从第三方源引入且在内省期间未“加载”的对象版本可能在此处丢失。您可以将任意历史版本与源代码的当前版本进行比较。

如果您是特定数据库的唯一用户,并且您仅从 DataGrip 更改源,Local History(本地历史记录)会提供对象变更的完整历史记录。 

文章就到这里了。 这个流程对于有些人来说可能比较陌生,特别是来自其他工具的用户,但遵循这一流程将免除重复操作,让工作更加轻松。

DataGrip 团队。

P.S. 截图使用的配色方案是 Monocai

本博文英文原作者:

Sue

Maksim Sobolevskiy

Discover more

News Tutorials

Working with source codes in DataGrip

Basics

The source code of the object is the core part of the DDL script which is needed to create this object. In other words, the CREATE statement is not part of the object’s source code. The source code is stored inside the database. The most common objects found with the source code are views, functions, and stored procedures.

In many other tools, to update the source code, you would need to generate the CREATE OR REPLACE script, make the required changes and run it. In DataGrip it works a little differently. You just need to make the changes you need to make and the proper script will be generated for you.

People coming from other tools all make the same mistake: they open the DDL, copy it, modify it, adjust the CREATE statement (usually add the OR REPLACE part) and run the new script. This is not the way you are supposed to update the source code.

Loading sources

For any data source, DataGrip performs the process called ‘introspection’ – the IDE retrieves all the metadata for objects in advance. This means that all source code is loaded when the introspection is performed.

You can manage this process by choosing the required value in the Load Sources for options in the data source properties.

In Oracle there is the possibility not to load sources by choosing a lower introspection level:

You might be asking: if the source code is loaded when introspection is performed, doesn’t it mean that they are out-dated?

Yes, it does. Handling this situation will be covered later in our tutorial.

The flow

Double-clicking on the object in the database explorer or pressing Cmd/Ctrl+B on it in the SQL script opens the DDL editor. In case of the view, double-clicking on it in the database explorer opens the data: to open the DDL explorer click on the DDL button in the toolbar.

The DDL editor will open. Here you can find the CREATE script for the object.

Important! The object references in the generated script are not qualified, in other words, %view_name% is used rather than the %schema_name%.%view_name%. The reason for this is the ability to copy the script for applying it in another context. If you want a script with qualified references, use the SQL generator.

In the DDL editor, you can change the source code. When you edit the source code of any object, DataGrip tracks changes and highlights them in the gutter. 

For example, add a comment line to a procedure or a function. The line you added is highlighted. If you click the highlighted line in the gutter, a small toolbar is displayed with the Show Diff button. You can click the Show Diff button to see the difference between the code that you added and the source code.

After you made the required changes, click the Submit button.

DataGrip will generate the modification script and show you a preview.

If you are okay with the result, click on OK and the script will be executed in the database. As a result, the required source code will be changed. 

DataGrip not only adds OR REPLACE to the creation script, but it can also handle more difficult situations, i.e. changing the object’s signature or object renaming. When it’s needed, DROP and CREATE scripts will be created.

Changing several objects at once

When the changes are made in the DDL editor, but not submitted yet, DataGrip stores them until you submit them. For example, if you changed several objects, several changed DDL are cached waiting for being applied. In the tool window called Database Changes, you can observe all pending source code changes and submit them all together at once.

Outdated cached objects

As we mentioned, DataGrip caches the source code which was loaded at the introspection. If an object that you opened was updated from a third-party location, you will see a notification that the cached object differs from the source code of the same object in the database.

If you see this warning in the IDE, you can choose one of the following actions to take:

  • Synchronize: fetch changes from the database and update the cached local object.
  • Disable check: disable this notification.

Also, there might be a conflict between your version of the object source code and that in the database. For example, when you have modified the same source code as someone else and clicked Submit.

You can forcefully replace the source code of the object in the database using Force Refactoring or you can synchronize the object state and then proceed with changes by clicking Abort Refactoring and Synchronize.

If you’ve selected Abort Refactoring and Synchronize, DataGrip aborts the submit operation and fetches the changes from the database just like if you had clicked Synchronize. If the conflict still exists, you will see the following notification.

In this notification, you can choose between the following options:

  • Revert local changes: roll back all your changes and replace them with the version from the database.
  • Keep local changes: use your changes and overwrite changes in the database.
  • Merge: display the diff dialog to merge the versions of the object source code.

Local history

All the changes you make to the source code are stored locally. If you want to go back in time and check the source code of the function before the latest updates you can do it with the help of Local History.

The revisions in Local History contain all your local changes and also include the versions retrieved from the database during introspections. So, the versions of the object that were introduced from third-party sources and not ‘loaded’ during the introspection may be missing here. You can compare any historical revision with the current version of the source code.

If you are the only user who works with a particular database, and you change sources only from DataGrip, Local History has a complete history of the objects’ changes. 

That’s it! We know that this flow can feel unfamiliar, especially if you came from the other tool, but following this flow will make your life easier by removing repetitive operations.

The DataGrip team.

P.S. The color scheme used for the screenshots is Monocai.

Discover more