Se eu quisesse fechar com base na data da última atividade (em vez da data de criação), existe uma variável para usar no lugar de created_at?
Existe alguma maneira de excluir mensagens diretas (DMs) de serem fechadas? Executei a consulta em meu ambiente de teste e notei que ela atingiu todos os tópicos, sejam eles públicos ou privados; gostaríamos de excluir mensagens privadas, se possível.
Em nosso fórum, temos quase 16 anos de conteúdo que importamos de nossa solução anterior. Em termos de tempo para executar a consulta, (a) como podemos determinar quanto tempo ela precisa ser executada e (b) seria melhor dividi-la (por exemplo, executar para tudo anterior a 2010, depois para 2011, 2012, etc., até chegarmos a 2023) ou apenas executá-la como uma única consulta?
Apenas tentando garantir (com a #4) que não impactemos muito o desempenho do sistema. Sei que muito depende do hardware em que estamos executando (que eu realmente não sei, porque temos uma equipe de infraestrutura que cuida da instalação em si e mantém todo o hardware).
No item nº 2, usando o plugin data explorer (que eu não conhecia), parece que updated_at é provavelmente o valor onde estaria o ‘timestamp da última resposta’. Essa é uma avaliação precisa?
Obrigado por esta dica - é muito útil para as minhas três primeiras perguntas, acho. Agradeceria alguma clareza sobre updated_at e o planejamento para operar em nosso histórico estendido de posts e tópicos.
Eu definitivamente testaria com um pequeno lote primeiro. Eu, uh, derrubei um site da comunidade com ações em massa e desejei ter testado um subconjunto primeiro.
Obrigado - eu suspeitava que esse pudesse ser o caso. É bom ter a confirmação da abordagem.
Acho que o que posso fazer é tentar extrair um dos backups recentes e configurar um ambiente de sandbox separado do meu ambiente de teste. Não tenho certeza de como a peça SSO funcionará nessa configuração, mas seria bom ver como o desempenho se parece antes de atingir o sistema de produção.
Vou observar que, se você tiver uma comunidade especialmente ativa, o site de staging não simulará completamente a produção, pois há algum impacto das pessoas usando o site organicamente, além das ações em massa.
Com certeza - agradeço também a indicação para o post do servidor de staging, isso será muito útil.
Sim, a carga de usuários provavelmente não será um grande problema - parece que nossas visualizações de página por dia são em torno de 50 mil, em média, em todos os (rastreadores, anônimos e usuários registrados). Entender o potencial aumento da carga em relação à carga existente será útil para fins de planejamento.
Eu acabei configurando um servidor de staging (foi bem fácil, na verdade - apenas restaurei um backup da produção e fiz login usando o procedimento de recuperação de administrador, já que está configurado apenas para OIDC). Parece que temos cerca de 160 mil tópicos, e um teste rápido em apenas uma categoria com cerca de 7500 levou 6 minutos no meu sistema de teste - então cerca de 2 horas para todos os tópicos. O impacto no desempenho do sistema (monitorado com htop) pareceu bem insignificante aqui.
Tenho certeza de que podemos encontrar um período de baixo uso onde o comando rake possa ser executado, e podemos preparar grupos de categorias se quisermos, então isso funcionará muito bem para nós.
Agradeço todas as dicas e ajuda - aprendi muito sobre a plataforma nos últimos dias como resultado.
