我們支持我們的實例與Oracle數據庫,發現下面的SQL做你問什麼:
注:您可能需要更新created_at
值別的東西,但我不認爲它會產生功能差異。
INSERT INTO properties (id, user_id, prop_key, text_value, is_empty, created_at)
SELECT
PROPERTIES_SEQ.nextval,
users.id,
'notification.SQ-MyNewIssues.EmailNotificationChannel',
'true',
0,
1505275000000
FROM
users
WHERE
users.id NOT IN (
SELECT user_id
FROM properties
WHERE prop_key = 'notification.SQ-MyNewIssues.EmailNotificationChannel');
INSERT INTO properties (id, user_id, prop_key, text_value, is_empty, created_at)
SELECT
PROPERTIES_SEQ.nextval,
users.id,
'notification.ChangesOnMyIssue.EmailNotificationChannel',
'true',
0,
1505275000000
FROM
users
WHERE
users.id NOT IN (
SELECT user_id
FROM properties
WHERE prop_key = 'notification.ChangesOnMyIssue.EmailNotificationChannel');
我試圖在某些時候將兩者結合起來,但是sql太複雜了。足夠簡單,只需複製粘貼。
G. Ann是用戶正確將創建因爲純粹的大宗通知的電子郵件過濾器,特別是如果你把他們所有上。然而,有時管理人員想要一個單方面的解決方案,如果產品不直接支持它,那麼無論如何你最終都不得不一起破解一些東西。
I reckon如果將信息合併到限速彙總中,則過濾電子郵件的動機將大大減少。我還有另一個關於這個特定場景的stackoverflow:Can SonarQube notification email quantity be reduced via batching?