suppress option for every rule

[dominickdm]

Hello,

Is it possible to add a supress option for every rule?

For example i'm unable to suppress the rule 'TableScanAndWhere'. I tried '{&proparse prolint-nowarn(TableScanAndWhere)}' and {&_proparse_prolint-nowarn(TableScanAndWhere)}, but both of them aren't suppressing the sonar issue

In some circumstances the TABLE-SCAN option seems to be faster, example below:

DEFINE VARIABLE i AS INTEGER NO-UNDO.
DEFINE VARIABLE id2 AS INTEGER NO-UNDO.

DEFINE TEMP-TABLE tt NO-undo
	FIELD x AS CHARACTER
	FIELD id AS int
	INDEX KEY id.


DO i = 1 TO 1000000:
    CREATE tt.
    tt.id = i.
    tt.x = string(i).
END.

ETIME(TRUE).
FOR EACH tt WHERE tt.x = "1"  TABLE-SCAN:
    id2 = tt.id.
END.
MESSAGE etime  VIEW-AS ALERT-BOX. /* +- 600 ms */


ETIME(TRUE).
FOR EACH tt
    WHERE tt.x = "1":
    id2 = tt.id.
END.
MESSAGE etime VIEW-AS ALERT-BOX.  /* +- 680 ms */

[movedoa]

I cannot believe that TABLE-SCAN would ever be faster than a correct index. Can you give any real world example of this?

[dominickdm]

I cannot believe that TABLE-SCAN would ever be faster than a correct index. Can you give any real world example of this?

Hello,

I was wrong, the example we have wasn't on a real database, but on a temp-table. Similar as the example above.

[movedoa]

But in the example you hit no index which means that TABLE-SCAN may be a bit faster but still way worse then defining a correct index.

I see no value in ever using TABLE-SCAN with a WHERE clause.

[jurjendijkstra]

regardless if this table-scan example is a valid example or not... I back the original question: what can you do to suppress a warning?

[gquerret]

It's possible to suppress issues directly in the code only this is implemented in the rule. But it's also possible to mark them as false positives in the web ui (also possible to do bulk changes). Issues marked as false positives won't appear anymore in the web interface AND in SonarLint.