トリガーされたカスタムバッジクエリの作成

[Discourse]

このガイドでは、Discourse でトリガーされるカスタムバッジクエリを作成する方法について、バッジの種類、トリガーされるバッジの制約、およびクエリの例を含めて説明します。

必要なユーザーレベル: 管理者

この機能はデフォルトで無効になっています。有効にするには、こちらのガイドに従ってください。

Discourse でバッジを定義する際、「トリガー」オプションが表示され、次の選択肢があります。

• 毎日更新
• ユーザーが投稿に対してアクションを実行したとき
• ユーザーが投稿を作成または編集したとき
• ユーザーが信頼レベルを変更したとき
• ユーザーが編集または作成されたとき

これらのトリガーは、バッジが毎日よりも頻繁な間隔で実行されることを強制し、アクションが発生したときにユーザーが新しいバッジをより早く通知されるようにします。

バッジの種類

定義できるバッジには 2 種類あります。

1. 投稿を対象とするバッジ
2. 投稿を対象としないバッジ

すべてのバッジ SQL 定義では、user_id と granted_at の列を選択する必要があります。バッジが投稿を対象とする場合は、post_id という名前の列も選択する必要があります。

これらの列が直接利用できない場合は、エイリアスを付けることができます。例: u.id as user_id

トリガーされるバッジの制約

トリガーされるバッジは 1 分間に 1 回実行される可能性があるため、バッジの定義により多くの「ヒント」を提供する必要があります。バッジの完全なセットを返すだけでは不十分であり、サブセットでバッジをどのように実行するかについてのヒントを提供する必要があります。

ユーザーベースのトリガー

トリガーがユーザーベースの場合、:user_ids に基づいてフィルタリングする方法の句を提供します。

投稿ベースのトリガー

トリガーが投稿ベースの場合、:post_ids に基づいてトリガーする方法に関する情報を提供します。

完全なバックフィルは毎日実行されることを忘れないでください。そのため、これを考慮に入れ、:backfill パラメータの処理を含める必要があります。

トリガーされるバッジクエリには、常に :backfill パラメータと、:post_ids パラメータまたは :user_ids パラメータのいずれかが含まれます。

トリガーされるバッジクエリの例

ここでは、「ユーザーが投稿に対してアクションを実行したとき」にトリガーされるバッジの例を示します。この場合、「デルタ」アプリケーションには :post_ids パラメータが渡されます。

SELECT p.user_id, p.id post_id, p.updated_at granted_at
FROM badge_posts p
WHERE p.like_count >= 25
AND (:backfill OR p.id IN (:post_ids) )

(:backfill OR p.id IN (:post_ids) ) 句により、結果をフィルタリングできます。毎日のジョブが実行されると、:backfill は true になり、セット全体がスキャンされます。デルタジョブが実行されると、:backfill は false になり、:post_ids が設定されます。

手動でのヒント設定が必要な理由

バッジ付与クエリは、バッジクエリを「サブクエリ」内で実行します。多くの場合、PostgreSQL のオプティマイザは、句がメインクエリ上にある場合に完全なセットをスキャンすると苦労します。ごく簡単なクエリは処理できても、より複雑な集計では失敗する可能性があります。

潜在的な問題を回避するために、この制約が追加され、最も適切な場所にフィルターを適用できるようになりました。

サポートが必要ですか？

バッジクエリの作成で行き詰まった場合は、Support で質問を投稿してください。達成しようとしていることを説明し、作業中のものを添付してください。コミュニティがサポートを試みます。

バッジのトリガーは複雑になることがあります。「毎日」の更新で十分な場合が多く、トリガーされるクエリのより複雑な側面を省略できることがよくあります。