When there are multiple active IDO instances on the same node, before this
commit, all of them would share a single DbValue object for the notification_id
column of the icinga_contactnotifications table. This resulted in the issue
that one database references the notification_id in another database.
This commit fixes this by using a separate DbValue value for each IDO instance.
This needs a new signal as the existing OnQuery and OnMultipleQueries signals
perform the same queries on all IDO instances, but different queries are needed
here per instance (they only differ in the referenced DbValue). Therefore, a
new signal OnMakeQueries is added that takes a std::function which is called
once per IDO instance and can access callbacks to perform one or multiple
queries only on this specific IDO instance.
They're actually not processed when the feature is paused,
and I have already seen them in user's logs when analysing why
objects are not updated or notifications sent. 'DbEvents' isn't
related to rather 'DB IDO' and is confusing.
It is just boolean mapping to numbers, each modules does that in a sort of different way.
DB IDO automatically transforms boolean to numbers.
Livestatus would return JSON which keeps true booleans, but requires a number (just a guess,
there is no spec for this message format).
What does this change?
* Remove use of spaces for formatting
These could be found by using `grep -r -l -P '^\t+ +[^*]'
* Removal of training whitespaces
* A few lines longer than 120 chars
We cannot add the notification insert id directly
to the following contactnotifications queries. Instead
we need to pass a DbValue reference which gets set after
the notification insert id is calculated.
The contactnotifications insert queries are fired as query
group calling CanExecuteQuery() and FieldToEscapedString().
If the notification id does not exist yet, the queries are
moved to the end of the queue.
Once the contactnotifications queries are fired the DbValue
reference is destroyed.
This patch also removes the old notification insert id cache
which was broken in many ways.
fixes#11387
Otherwise the changes from #7287 already take care of setting
the proper next check time from inside ProcessCheckResult().
There is no need to use the generic OnNextCheckChanged signal
but instead we're using a new one, locally just for DB IDO.
fixes#11019
