Mon parcours de migration phpBB (postgresql)

Migration
21

les publications supprimées de manière logicielle sont importées comme des publications normales (et sont visibles). c’est clairement un problème car je pense que les utilisateurs suppriment de manière logicielle par défaut, et les publications supprimées peuvent contenir des informations sensibles.

les colonnes pertinentes incluent : post_delete_user, post_delete_time, post_visibility, post_delete_reason

il semble que post_visibility soit la seule pertinente — les autres valeurs de colonne ne sont pas effacées si une publication est supprimée de manière logicielle puis restaurée. normal = 1, invisible = 2

ma solution est de simplement ignorer les publications supprimées de manière logicielle car personne ne s’en soucie.

exécutez ceci sur votre base de données source avant la migration :

DELETE FROM phpbb_posts WHERE post_visibility = 2;
1 « J'aime »
22

J’ai un pipeline de « migration continue » pour les pauvres. C’est un ensemble de scripts shell pour effectuer des tâches telles que :

  • extraire la base de données phpbb, les pièces jointes, etc. du serveur distant
  • créer/gérer des instances discourse
  • des site_settings spécifiques sont appliqués lorsqu’une instance discourse est créée à partir d’une instance modèle
  • les sauvegarder/restaurer
  • exécuter la migration avec un ensemble spécifique de scripts d’importation à partir d’un dépôt git
  • effectuer des tâches post-migration

Essentiellement, cela me permet de travailler sur une instance discourse dctemplate pré-migration avec laquelle je joue. Je continue à ajuster les paramètres de discourse à ma convenance.

Chaque nuit, j’extrais les données du phpbb live existant et j’effectue une nouvelle migration sur une nouvelle instance discourse (dcstaging) nouvellement créée à partir du modèle le plus récent.

Cela prend des heures, bien sûr, j’ai donc aussi un phpbb local en cours d’exécution avec une base de données très petite que j’utilise pour effectuer des tests et améliorer les scripts de migration. Je peux effectuer des migrations relativement rapides pour tester sur une autre instance discourse (dcdev).

Le flux de travail de test pendant la journée ressemble donc à ceci :

J’ai fait du travail sur le modèle, j’aime où j’en suis :

./dc_template_create.sh dctemplate

Oups, j’ai fait une erreur sur mon modèle. Je le restaure à l’état précédent :

./dc_template_restore.sh dctemplate

Je fais une migration rapide pour tester certaines choses :

# crée une nouvelle instance dcdev à partir de dctemplate (et applique des site_settings spécifiques à dcdev)
./dc_template_restore.sh dcdev dctemplate
./dc_migrate.sh dcdev # s'exécute avec le dépôt de script de migration spécifique à cette instance

Je fais une longue migration pendant la nuit à partir du vrai phpbb live :

./dc_template_create.sh dctemplate
./dc_template_restore.sh dcstaging dctemplate

./phpbb_pull.sh
./dc_migrate.sh dcstaging
sleep 300
./dc_rake.sh dcstaging # tâches post-migration supplémentaires non gérées par l'importateur pour (créer des modérateurs, un étiquetage détaillé, déplacer certains sujets, etc.)

Si quelqu’un est suffisamment intéressé, je pourrais le nettoyer un peu et le partager.

2 « J'aime »
23

Discourse possède des tags, il pourrait donc être judicieux de les utiliser et de supprimer les sous-catégories lorsque cela est pertinent.

Mes sous-catégories avaient chacune plusieurs sujets épinglés/collés, et lorsqu’ils sont combinés dans une grande catégorie, cela fait beaucoup trop de sujets épinglés. C’est perturbant.

Ma solution a été de passer de catégories comme :

Food
- American
- Chinese
- ...

à ceci :

Food
- Featured

Les catégories américaine, chinoise, etc. deviennent des tags, et tous les sujets épinglés vont dans “Featured” et sont désépinglés.

# Désépingle tous les sujets épinglés d'une catégorie et les déplace vers une sous-catégorie
def move_pinned_topics_to_subcategory(category, subcategory_name)
  subcategory = Category.where(name: subcategory_name).find_by(parent_category_id: category.id)
  topics = Topic.where(category_id: category.id).where.not(pinned_at: nil)
  topics.each do |topic|
    topic.update(pinned_at: nil, pinned_globally: false, pinned_until: nil,
      category_id: subcategory.id) if not topic.title[/About the .+ category/]
  end
  Category.update_stats
end

food_cat = Category.find_by(name: 'Food')
move_pinned_topics_to_subcategory(food_cat, 'Featured')
4 « J'aime »
24

mon forum a en fait aussi une incarnation précédente et morte (également phpBB) dont nous avons un wget siterip, donc je travaille sur un importateur pour cela. analyser les fichiers html avec nokogiri, ingérer dans une base de données intermédiaire, puis travailler avec la classe de base de l’importateur pour obtenir des lignes dans discourse.

j’ai vu ceci :

je suppose que c’est un problème peu courant, mais si quelqu’un d’autre est confronté à ce problème, peut-être que j’y mettrai un peu plus de soin et que je le partagerai. faites-moi savoir.

ou si quelqu’un l’a déjà fait et veut partager avec moi, c’est encore mieux. je ne suis pas encore très loin dans le projet.

2 « J'aime »