Bonjour à tous, On 19/01/2012 08:34, Remi Collet wrote:
Une proposition d'évolution pour la gestion des éléments importésExemple, table glpi_computervirtualmachines Ajout de 2 champs - is_dynamic => importé - is_deleted => supprimé (verrouillé dans ce cas) Lors de la suppression si is_dynamic=1 => passer is_deleted=1 (sinon purger, comme d'hab) Gestion des verrous VM verrouillées : is_dynamic=1 ET is_deleted=1 Deverrouiller => is_deleted=0Lors de l'import OCS, au lieu de prendre le contenu de glpi_ocslinks.import_vm, on fait unSELECT ... WHERE computers_id=xx AND is_dynamic Avantages :- méthode standard déjà utilisée pour les utilisateurs (droits et groupes)- méthode indépendante de l'outil d'import (Fusion doit pouvoir l'utiliser, à confirmer, David ?) - gestion plus légèreglpi_ocslinks, je trouve ça lourd, avec 2Gio (sur 13Gio), c'est la plus grosse table chez nous, après glpi_logs (9Gio) et avant les install (1.4Gio)- moins d'UPDATE (maj de glpi_ocslinks) Inconvénients : - plus de SELECT pendant la synchro, mais bon, on utilise un index. - ce que j'ai probablement raté Ensuite, à généraliser aux autres données : - glpi_computers_device*(là de toutes manières faut revoir tout le schéma pour les champs "specificity")- glpi_computerdisks - glpi_computers_softwareversions - glpi_computers_items(monitor, peripheral, printer et donc phone, même si pas utiliser par OCS)
J'ai un peu de mal à voir au niveau migration. Dans import_printer par exemple on a des enregistrement qui n'existent plus dans glpi_computers_items, donc comment garder le verrou : recréer les enregistrements et mettre is_dynamic=1 && is_deleted=1 ?
Cordialement, Walid. _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
