Dans l'hypothèse où ton cas se résoud bien de cette façon... :
Il y a un catalogue qui indexe les objets qui s'y conforment (quasi automatiquement) et remet à plat la hiérarchie. Bref t'obtiens une liste de tous tes objets, indexés sur les champs de ton choix.
L'algo donnerait :
- demander au catalogue tous les objets de type tonTypeAMettreAJour avec peut-être certaines restriction sur les index pour bien cibler le travail de recherche
- pour chaque entrée du catalogue:
- récupérer une référence sur le véritable objet (pas le « brain » que stocke le catalogue)
- changer la valeur de l'attribut
Voilà ! S'il n'y a une aucune exception de soulevée, la transaction a été validée et les attributs ont été mis à jour.
Tu me dira qu'installer un catalogue pour faire la migration d'objets peut être lourde mais dis-toi :
- qu'un objet ne se conçoit pas comme une table dans un SGBDR. Tu peux par exemple imaginer une méthode de mise à jour et des assertions pour détecter quand il faut la pratiquer, alors que les nouvelles instances auraient déjà ces assertions de validées (TODO réfléchir à ce que je viens la tête au frais).
- que souvent tu travailles dans un framework genre CMF/CPS/Plone donc le catalogue est déjà en place et rempli et que t'as des scripts genre cpsupdate qu'on t'invite à lancer pour pratiquer la mise à jour d'une instance de site.
[^] # Re: PoPy et PygreSQL s'unissent pour le meilleur
Posté par Ramso . En réponse à la dépêche PoPy et PygreSQL s'unissent pour le meilleur. Évalué à 5.
Il y a un catalogue qui indexe les objets qui s'y conforment (quasi automatiquement) et remet à plat la hiérarchie. Bref t'obtiens une liste de tous tes objets, indexés sur les champs de ton choix.
L'algo donnerait :
- demander au catalogue tous les objets de type tonTypeAMettreAJour avec peut-être certaines restriction sur les index pour bien cibler le travail de recherche
- pour chaque entrée du catalogue:
- récupérer une référence sur le véritable objet (pas le « brain » que stocke le catalogue)
- changer la valeur de l'attribut
les secrets les plus intimes du catalogue et ses indexes sont ici :
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Searchi(...)
(encore plus intime, il y a la lecture du code source :))
Voilà ! S'il n'y a une aucune exception de soulevée, la transaction a été validée et les attributs ont été mis à jour.
Tu me dira qu'installer un catalogue pour faire la migration d'objets peut être lourde mais dis-toi :
- qu'un objet ne se conçoit pas comme une table dans un SGBDR. Tu peux par exemple imaginer une méthode de mise à jour et des assertions pour détecter quand il faut la pratiquer, alors que les nouvelles instances auraient déjà ces assertions de validées (TODO réfléchir à ce que je viens la tête au frais).
- que souvent tu travailles dans un framework genre CMF/CPS/Plone donc le catalogue est déjà en place et rempli et que t'as des scripts genre cpsupdate qu'on t'invite à lancer pour pratiquer la mise à jour d'une instance de site.