dbLinter - Our Newest Product

We are excited to announce that we partnered with Grisselbav (Philipp Salvisberg) to deliver state-of-the-art database code quality tools for databases called dbLinter. Our current focus is static code analysis for code running in an Oracle Database (SQL and PL/SQL) and SQL-based tests that execute SQL queries to find rule violations. We will extend support for PostgreSQL databases in the future as well.

Why Database Linting Matters

The data model and the business rules within the database (e.g., in PL/SQL) are some of the most critical pieces of software companies have. Linters can parse and analyze your code for rule violations. The violations are displayed directly in the developer's code editor or reported in pipelines that run automated scans. This makes linting a powerful approach by maintaining good code quality by scanning software automatically and enforcing good practices and company standards.

Here is an example where the linter catches an Oracle PL/SQL error log without stack trace details.

How does the linter know this is an issue? The linter comes with a predefined set of rules. In the example above, the rule is called "Always use FORMAT_ERROR_BACKTRACE when using FORMAT_ERROR_STACK or SQLERRM."

Comprehensive Rules Repository

dbLinter ships with numerous rules, which you can discover in our rules repository at dblinter-rules.united-codes.com. It currently consists of over 180 rules, which we look forward to extending over time (we are already planning some APEX-specific rules). The rules' website displays all the rules with non-compliant and correct examples, in-depth descriptions, and categories for which you can filter.

Many of these rules are migrated from the Trivadis PL/SQL and SQL Coding Guidelines, which Philipp Salvisberg maintained for years. He also built Trivadis db* CODECOP, which was a similar linter tool that was discontinued and where dbLinter is a replacement.

Many of the rules can be customized to your needs through parameters. This is great for configuring rules to fit your company's standards. A great example is naming standards like the one for primary keys. It doesn’t matter what naming convention you use, but it should be consistent. You can just customize the regex to fit your needs.

In coming versions, there will also be a way to define new rules that can be implemented as a check or test (SQL query).

Enterprise-Ready with Tenants and Developer Tools

dbLinter will feature a tenant architecture with central configurations. A configuration consists of file patterns for inclusion/exclusion, rules, validators, tests, parameters, custom parameters, test results to be ignored, and the connect information for read-only database access within checks and tests. A configuration ensures consistent use across all dbLinter tools and users.

The easiest way to onboard developers will be the VS Code extension, which lints your code while you edit it. It will mark rule violations with a link to the rule page, offer quick fixes, or allow you to ignore them. Thanks to the standardized language server protocol, VS Code will not be the only editor supported, but it is the one we are starting with.

Roadmap and Availability

dbLinter is under active development, and publishing the rules website marks the first phase until it reaches the 1.0 version. dbLinter will be a subscription-based tool suite. Paid subscriptions will be based on how many developers use it. Philipp Salvisberg is working hard to deliver the VS Code extension soon, which also allows usage with basic features for free. We aim to keep extending the rule repository and eventually add Postgres support.

If you attend APEX Connect, make sure to attend his sessions, during which he will share more insights. We are happy and excited that he partnered with us and can’t wait to use dbLinter to ensure the quality of our code as well.

If you want to stay informed, sign up for the dbLinter newsletter, where we occasionally share updates.