Ignoring Issues

@dbLinter Ignore Marker Comment

If you are unable to fix a problem or choose not to, you can add a @dbLinter ignore marker to indicate that the problem is being intentionally accepted. This avoids making unnecessary or unsafe changes and keeps the linting output meaningful rather than noisy.

Syntax

The @dbLinter marker comment must be placed within a single-line or multiline comment, and is case-insensitive.

@DBLINTER IGNORE(rule1 [, rule2]...) [comment]

The syntax of a rule is as follows:

[tenantName] ruleName

If you omit the tenantName, the ruleName is expected to exist in the Core tenant.

Scope

If the dbLinter marker comment is not the only visible token on a line, the scope is limited to that line only.

If the dbLinter marker comment is the only visible token on a line, the scope is determined by the innermost parser rule context that fully contains the comment.

The following IslandSQL parser rules are considered:

The following APEXlang parser rules are considered:

If the dbLinter marker comment is placed before the first token recognised by the parser, the scope is the whole file.

Please note that APEXlang does not allow comments after a propertyValue because the comment would be interpreted as part of the property value.

PL/SQL Examples

The scope of the dbLinter marker comment is visualised using highlighted lines in the examples below.

declare
   l_var1 integer;
   procedure proc1 is
      l_var2 integer;
      procedure proc2 is
         l_var3 integer; -- @dbLinter ignore(G-1030)
         l_var4 integer;
      begin
         null;
      end;
   begin
      proc2;
   end;
begin
   proc1;
end;
/

declare
   l_var1 integer;
   procedure proc1 is
      l_var2 integer;
      procedure proc2 is
         -- @dbLinter ignore(G-1030, G-7120)
         l_var3 integer;
         l_var4 integer;
      begin
         null;
      end;
   begin
      proc2;
   end;
begin
   proc1;
end;
/

declare
   l_var1 integer;
   procedure proc1 is
      -- @dbLinter ignore(G-1030, G-7120)
      l_var2 integer;
      procedure proc2 is
         l_var3 integer;
         l_var4 integer;
      begin
         null;
      end;
   begin
      proc2;
   end;
begin
   proc1;
end;
/

declare
   -- @dbLinter ignore(G-1030, G-7120)
   l_var1 integer;
   procedure proc1 is
      l_var2 integer;
      procedure proc2 is
         l_var3 integer;
         l_var4 integer;
      begin
         null;
      end;
   begin
      proc2;
   end;
begin
   proc1;
end;
/

-- @dbLinter ignore(G-1030, G-7120)
declare
   l_var1 integer;
   procedure proc1 is
      l_var2 integer;
      procedure proc2 is
         l_var3 integer;
         l_var4 integer;
      begin
         null;
      end;
   begin
      proc2;
   end;
begin
   proc1;
end;
/

APEXlang Examples

The scope of the dbLinter marker comment is visualised using highlighted lines in the examples below.

app demo (
    security {
        /* @dblinter ignore(A-0770) */ embedInFrames: allow
    }
)

app demo (
    security {
        // @dblinter ignore(A-0770)
        embedInFrames: allow
    }
)

app demo (
    // @dblinter ignore(A-0770)
    security {
        embedInFrames: allow
    }
)
// more...

// @dblinter ignore(A-0770)
app demo (
    security {
        embedInFrames: allow
    }
)
// more...

.dblinterapxignore

Re-exporting an APEX application overwrites comments added to its APEXlang files. Use a .dblinterapxignore file to preserve these exceptions across exports, and commit it to version control alongside your application. You can still use @dbLinter ignore() marker comments in SQL and PL/SQL blocks within APEX files.

Location

Place .dblinterapxignore in the workspace root, outside the application export directory. The CLI and SonarQube plugin each support one workspace root. VS Code supports multiple workspace roots, each with its own .dblinterapxignore file.

Syntax

Each ignore entry occupies one line:

file-pattern; scope; rule1 [, rule2]... # optional reason

file-pattern selects APEXlang files using the same glob patterns as configurations. For example, **/pages/page_10.apx matches that path under any directory.
scope selects a component (region orders ()), group (settings {}), or property (valueProtected). Nest selectors to narrow the target: region employees (type) selects only that component’s type property. Empty () or {} selects the container and its contents. The outermost selector can match anywhere in the file; file selects the whole file.
rules is a comma-separated list of rules, with the same optional tenant prefix as marker comments. Rules without a tenant prefix belong to Core.
# starts an optional reason or a comment line.

Examples

The following .dblinterapxignore entries correspond to the APEXlang marker examples above. Each line shows an alternative scope:

**/application.apx; app demo (security {embedInFrames}); A-0770 # Property embedInFrames (single-line marker)
**/application.apx; app demo (security {}); A-0770              # Group security
**/application.apx; app demo (); A-0770                         # Component app
**/application.apx; file; A-0770                                # Whole file

A property selector on its own, such as embedInFrames, selects all properties with that name in the matching files. According to the APEXlang EBNF grammar embedInFrames is only defined in the app’s security group. In this case, the first entry in the previous example could be abbreviated as follows without accidentally hiding other issues:

**/application.apx; embedInFrames; A-0770