Bonjour,
J'ai en partie implémenté la partie gestion des locks (reste les
composants et les cartes réseaux).
Autant pour le lock des champs pas de soucis je vois bien, autant pour
celle des liaisons je ne vois pas dans quels cas on a intérêt à les locker.
Si l'info est remontée automatiquement par l'outil d'inventaire, à quoi
cela sert-il de supprimer une liaison manuellement ? Dans le cas de
FusionInventory, on a pas de lock de liaison, c'est donc directement lié
à la synchro OCS.
La deuxième question induite est que, dans le nouveau système, lorsque
l'on délocke une liaison, celle-ci réapparaît automatiquement dans
l'inventaire (alors qu'en 0.83 la liaison n'apparaît qu'après avoir
reforcé la synchro OCS).
Bref,
Je suis preneur d'exemples afin de comprendre en détail à quoi cela sert
vraiment.
Walid.
On 19/01/2012 08:34, Remi Collet wrote:
Une proposition d'évolution pour la gestion des éléments importés
Exemple, 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=0
Lors de l'import OCS, au lieu de prendre le contenu de
glpi_ocslinks.import_vm, on fait un
SELECT ... 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ère
glpi_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)
- glpi_networkports (qu'il faut réécrire suite aux travaux de Damien)
Il me semblerait intéressant de réaliser ce chantier en pré-requis à
la sortie d'OCS en plugin.
Voila, pour avis... (oui, c'est un gros chantier, avec une très grosse
migration)
Remi.
*****************************************************
"Le contenu de ce courriel et ses éventuelles pièces jointes sont
confidentiels. Ils s'adressent exclusivement à la personne
destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez
reçu par erreur, et afin de ne pas violer le secret des
correspondances, vous ne devez pas le transmettre à d'autres personnes
ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.
Attention : L'organisme de l'émetteur du message ne pourra être tenu
responsable de l'altération du présent courriel. Il appartient au
destinataire de vérifier que les messages et pièces jointes reçus ne
contiennent pas de virus. Les opinions contenues dans ce courriel et
ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne
reflètent pas la position de l'organisme sauf s'il en est disposé
autrement dans le présent courriel."
******************************************************
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
