Erreur : entier hors de portée

Contribuer Bug
26

Je pense que nous sommes tirés d’affaire !

Nous avons constaté que nous devions migrer les colonnes dans d’autres tables qui référençaient notification_id en plus de notifications.id lui-même. Sinon, services/notifications.rb ou services/badge_granter.rb généreraient des erreurs.

Pour toute autre configuration de forum importante qui rencontrera ce problème à l’avenir avec les notifications, voici ce que nous avons fait…

Au total, nous avons dû migrer quatre colonnes dans quatre tables :

  1. notifications.id
  2. user.seen_notification_id
  3. user_badges.notification_id
  4. shelved_notifications.notification_id

Nous avons initialement procédé pour le point n°1 avec la commande ALTER suggérée ci-dessus, mais nous avons ensuite opté, comme mentionné, pour utiliser les migrations ActiveRecord, de sorte que les fichiers de migration s’ajoutent au schéma.

20230215070319_change_notifications_id_to_bigint.rb 
# frozen_string_literal: true

class ChangeNotificationsIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :notifications, :id, :bigint
    end
end
20230215070320_change_user_seen_notification_id_to_bigint.rb 
# frozen_string_literal: true

class ChangeUserSeenNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :users, :seen_notification_id, :bigint
    end
end
20230215070321_change_user_badges_notification_id_to_bigint.rb 
# frozen_string_literal: true

class ChangeUserBadgesNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :user_badges, :notification_id, :bigint
    end
end
20230215070322_change_shelved_notifications_notification_id_to_bigint.rb 
# frozen_string_literal: true

class ChangeShelvedNotificationsNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :shelved_notifications, :notification_id, :bigint
    end
end

Nous avons un Dockerfile personnalisé dans notre configuration (nous construisons des images afin de pouvoir exécuter discourse et sidekiq sur des ressources distinctes dans Kubernetes), donc copier ces fichiers dans /db/migrate dans le cadre de notre Dockerfile a été simple.

Ensuite, nous avons simplement laissé rake db:migrate s’occuper du reste. Une fois que nous avons effectué un redémarrage progressif de tous nos pods discourse et sidekiq, tout fonctionnait comme prévu :crossed_fingers:.

3 « J'aime »