discourse/app/jobs/scheduled/grant_anniversary_badges.rb

# frozen_string_literal: true

module Jobs
  class GrantAnniversaryBadges < ::Jobs::Scheduled
    every 1.day

    def execute(args)
      return unless SiteSetting.enable_badges?
      return unless badge = Badge.find_by(id: Badge::Anniversary, enabled: true)

      start_date = args[:start_date] || 1.year.ago
      end_date = start_date + 1.year

      sql = BadgeQueries.anniversaries(start_date, end_date)
      user_ids = DB.query_single(sql)

      User
        .where(id: user_ids)
        .find_each { |user| BadgeGranter.grant(badge, user, created_at: end_date) }
    end
  end
end
DEV: enable frozen string literal on all files This reduces chances of errors where consumers of strings mutate inputs and reduces memory usage of the app. Test suite passes now, but there may be some stuff left, so we will run a few sites on a branch prior to merging 2019-05-02 17:17:27 -05:00			`# frozen_string_literal: true`

Change Anniversary badge to be multiple grant, once per year 2017-04-28 11:20:05 -05:00			`module Jobs`
DEV: Upgrading Discourse to Zeitwerk (#8098) Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains. We no longer need to use Rails "require_dependency" anywhere and instead can just use standard Ruby patterns to require files. This is a far reaching change and we expect some followups here. 2019-10-01 23:01:53 -05:00			`class GrantAnniversaryBadges < ::Jobs::Scheduled`
Change Anniversary badge to be multiple grant, once per year 2017-04-28 11:20:05 -05:00			`every 1.day`

			`def execute(args)`
			`return unless SiteSetting.enable_badges?`
DEV: extract anniversary badge query (#19716) So it can easily be overwritten in a plugin for example. ### Added more tests to provide better coverage We previously only had `u.silenced_till IS NULL` but I made it consistent with pretty much every other places where we check for "active" users. These two new lines do change the query a tiny bit though. Before - You could not get the badge if you were currently silenced (no matter what period is being checked) - You could get the badge if you were suspended 😬 After - You can't get the badge if you were silenced during the past year - You can't get the badge if you were suspended during the past year ### Improved the performance of the query by using `NOT EXISTS` instead of `LEFT JOIN / COUNT() = 0` There is no difference in behaviour between ```sql LEFT JOIN user_badges AS ub ON ub.user_id = u.id AND ... [...] HAVING COUNT(ub.*) = 0 ``` and ```sql NOT EXISTS (SELECT 1 FROM user_badges AS ub WHERE ub.user_id = u.id AND ...) ``` The only difference is performance-wise. The `NOT EXISTS` is 10-30% faster on very large databases (aka. posts and users in X millions). I checked on 3 of the largest datasets I could find. 2023-01-16 04:55:00 -06:00			`return unless badge = Badge.find_by(id: Badge::Anniversary, enabled: true)`
Change Anniversary badge to be multiple grant, once per year 2017-04-28 11:20:05 -05:00
			`start_date = args[:start_date] \|\| 1.year.ago`
			`end_date = start_date + 1.year`

DEV: extract anniversary badge query (#19716) So it can easily be overwritten in a plugin for example. ### Added more tests to provide better coverage We previously only had `u.silenced_till IS NULL` but I made it consistent with pretty much every other places where we check for "active" users. These two new lines do change the query a tiny bit though. Before - You could not get the badge if you were currently silenced (no matter what period is being checked) - You could get the badge if you were suspended 😬 After - You can't get the badge if you were silenced during the past year - You can't get the badge if you were suspended during the past year ### Improved the performance of the query by using `NOT EXISTS` instead of `LEFT JOIN / COUNT() = 0` There is no difference in behaviour between ```sql LEFT JOIN user_badges AS ub ON ub.user_id = u.id AND ... [...] HAVING COUNT(ub.*) = 0 ``` and ```sql NOT EXISTS (SELECT 1 FROM user_badges AS ub WHERE ub.user_id = u.id AND ...) ``` The only difference is performance-wise. The `NOT EXISTS` is 10-30% faster on very large databases (aka. posts and users in X millions). I checked on 3 of the largest datasets I could find. 2023-01-16 04:55:00 -06:00			`sql = BadgeQueries.anniversaries(start_date, end_date)`
			`user_ids = DB.query_single(sql)`
Change Anniversary badge to be multiple grant, once per year 2017-04-28 11:20:05 -05:00
PERF: Fetch users in batches in grant anniversary badge job. 2017-06-23 02:53:07 -05:00			`User`
			`.where(id: user_ids)`
Change Anniversary badge to be multiple grant, once per year 2017-04-28 11:20:05 -05:00			`.find_each { \|user\| BadgeGranter.grant(badge, user, created_at: end_date) }`
			`end`
			`end`
			`end`