Existe-t-il une méthode plus récente pour le faire ?
Si je voulais fermer en fonction de la date de la dernière activité (plutôt que de la date de création), existe-t-il une variable à utiliser à la place de created_at ?
Existe-t-il un moyen d’exclure les messages privés (DM) de la fermeture ? J’ai exécuté la requête dans mon environnement de test et j’ai remarqué qu’elle touchait tous les sujets, qu’ils soient publics ou privés ; nous aimerions exclure les messages privés si possible.
Sur notre forum, nous avons près de 16 ans de contenu que nous avons importé de notre solution précédente. En termes de temps d’exécution de la requête, (a) comment pouvons-nous déterminer combien de temps elle prendra, et (b) serait-il préférable de la diviser (par exemple, exécuter pour tout ce qui est antérieur à 2010, puis pour 2011, 2012, etc., jusqu’à 2023) ou de l’exécuter en une seule requête ?
J’essaie juste de m’assurer (avec le point 4) que nous n’impactons pas trop les performances du système. Je sais que cela dépend beaucoup du matériel sur lequel nous fonctionnons (dont je ne connais pas les détails, car nous avons une équipe d’infrastructure qui gère l’installation elle-même et maintient tout le matériel).
Sur le point n°2, en utilisant le plugin d’exploration de données (dont j’ignorais l’existence), il semble que updated_at soit probablement la valeur où se trouverait le « timestamp du dernier message ». Est-ce une évaluation exacte ?
Merci pour cette indication - c’est très utile pour mes trois premières questions, je pense. J’apprécierais des éclaircissements sur updated_at et la planification d’opérer sur notre historique étendu de publications et de sujets.
Je testerais certainement d’abord avec un petit lot. J’ai, euh, mis hors service un site communautaire avec des actions groupées et j’aurais souhaité avoir testé un sous-ensemble d’abord.
Merci - je soupçonnais que ce soit le cas. C’est bien d’avoir confirmation de l’approche.
Je pense que ce que je vais faire, c’est essayer de récupérer une des sauvegardes récentes et de mettre en place un environnement bac à sable séparé de mon environnement de test. Je ne suis pas sûr du fonctionnement de la pièce SSO dans cette configuration, mais ce serait bien de voir à quoi ressemble la performance avant de toucher au système de production.
Je noterai que si vous avez une communauté particulièrement active, le site de staging ne simulera pas complètement la production car il y a un certain impact dû à l’utilisation organique du site en plus des actions groupées.
Absolument - j’apprécie également le renvoi à la publication du serveur de staging, ce sera très utile.
Oui, la charge utilisateur ne devrait pas poser de problème majeur - il semble que nos vues de page par jour soient d’environ 50 000 en moyenne sur l’ensemble (robots d’exploration, utilisateurs anonymes et enregistrés). Comprendre l’augmentation potentielle de la charge par rapport à la charge existante sera utile à des fins de planification.
J’ai fini par configurer un serveur de staging (c’était en fait assez facile - j’ai simplement restauré une sauvegarde de production et je me suis connecté en utilisant la procédure de récupération d’administrateur, car il est configuré uniquement pour l’OIDC). Il semble que nous ayons environ 160 000 sujets, et un test rapide sur une seule catégorie avec environ 7 500 a pris 6 minutes sur mon système de test - donc environ 2 heures pour tous les sujets. L’impact sur les performances du système (surveillé avec htop) a semblé assez négligeable ici.
Je suis sûr que nous pouvons trouver une période de faible utilisation où la commande rake peut être exécutée, et nous pouvons mettre en scène des groupes de catégories si nous le souhaitons, donc cela fonctionnera très bien pour nous.
J’apprécie tous les conseils et l’aide - j’ai beaucoup appris sur la plateforme au cours des derniers jours en conséquence.
