In 3.6, persistence of issues was fixed with
SONAR-4309 to support the following use case (at this time the scanner was persisting into the DB directly and Compute Engine did not exist, btw).
During the processing of a report, issues are read from DB to be merged with issues in the report (aka. issue tracking) and are persisted to DB later during report processing. If a modification is done to one of those issues during the time the issue is read and the issue is persisted (eg. issue is closed as won't fix), the new state of the issue should be taken into account.
SONAR-4309 fixed that.
However, a change in which occurred before 15/01/2015 (history is hard to track before this date on this file) broke the fixed introduced by
Therefore, since then, this use case is not supported anymore but not only.
Another consequence of the breaking change (see below) is that if an issue has been updated in the UI, the issue is not changed by the analysis at all:
- if the issue was closed by the analysis, it's not
- if the issue was moved by the analysis, it's not
The fix introduced by
SONAR-4309 relies on an update based on the date of the issue at the time it was read. If the issue has been changed in the UI, then this update will return 0 line changed (ie. no update). If so, we read the current state of the issue from DB, merge it with the issue we wanted to persist and persist the result in DB.
The breaking change was to make the persistence of issues to use a batch session. In Batch sessions, update always return a value < 0. Therefor the fix is not working anymore and no update in DB on the issue is done at all.
It's important to note that the approach used to fix
SONAR-4309 is incompatible with batch session and therefor poses a performance issue.