Pouah. La réponse est vraiment compliquée et nécessite beaucoup de connaissances d'ArcSDE, je vais donc essayer d'être aussi bref que possible.
Remarque Je vais me référer à certains diagrammes du livre blanc de version super génial que vous pouvez trouver sur le site ESRI . Si vous avez affaire au contrôle de version, je vous encourage vivement à le lire attentivement.
Ensuite, vous devez comprendre quelle est la relation entre un état (c'est-à-dire un nœud de l'arbre d'état) et une version nommée (c'est-à-dire une étiquette pointant vers un état).
Une base de données typique peut ressembler au diagramme d'état ci-dessous:
Ici, vous avez quatre versions dans la base de données (Version A, Version B, Version C et DEFAULT). Mais peut-être que j'ai un peu d'avance sur moi. Commençons par ce qu'est un état .
Vous pouvez considérer un état comme une "transaction" - une unité logique qui contient plusieurs modifications sur une ou plusieurs tables. Il peut inclure deux insertions à "FeatureClass A", une suppression de "Feature Class B" et une modification (en fait une suppression + un insert) à "Feature Class X". Tous regroupés en un seul.
Regardons un petit diagramme d'état ArcSDE simple qui commence à l'ID d'état 0:
Si vous commencez à l'état 0 et que vous effectuez des modifications sur une ou plusieurs tables dans une opération de modification, vous allez créer un état enfant 1 et en faire celui d' ID d'état actif actuel . Un autre groupe de modifications ultérieures créera l'état enfant 2. Si vous souhaitez annuler, vous n'avez pas besoin de modifier l'ID d'état en aucune façon - tout ce que vous devez faire est de changer l'ID d'état actif actuel à 1 ou 0 (selon jusqu'où vous voulez aller). Un rétablissement est l'inverse - déplacez simplement l'ID de l'état actif actuel vers l'avant - aussi loin que vous le souhaitez.
C'est ainsi que l'annulation / la restauration fonctionne dans la version d'ArcSDE.
OK, continuons. Supposons que vous souhaitiez rendre une modification permanente (c'est-à-dire que vous souhaitez enregistrer). Que dois-tu faire? Eh bien, enregistrer, c'est simplement saisir une étiquette de version et la déplacer vers un état particulier. Un peu comme l’estampiller et dire "voici à quoi doit ressembler la version A". Donc, si vous regardez en arrière le premier diagramme, vous verrez qu'il a quatre versions nommées .
- La version B pointe vers l'état id 1
- La version A pointe vers l'état id 3
- La version C pointe vers l'état id 5
La version "SDE.DEFAULT" pointe vers l'ID d'état 4
Veuillez noter que ce diagramme, malgré la croyance populaire, ne vous dit rien sur la relation logique parent-enfant qu'ils ont. La relation parent-enfant logique pour le premier diagramme pourrait effectivement ressembler à ceci:
Il s'agit de la relation parent-enfant que vous voyez dans ArcMap / ArcCatalog. Son but est de restreindre les versions avec lesquelles vous pouvez vous réconcilier. À ce stade, vous pourriez (à juste titre) vous demander, pourquoi diable ai-je besoin de cela? La réponse réside dans les workflows de gestion des versions . Il s'avère que les gens utilisent le versionnage depuis un certain temps et il existe des façons préférées de les structurer, mais c'est un sujet pour un autre jour car je veux répondre à votre question aujourd'hui :)
Continuons ...
OK, alors que font les autres versions nommées? Eh bien, ils affectent le comportement de ce processus appelé compress .
La compression consiste à récupérer des états intermédiaires qui peuvent ne pas être nécessaires, à supprimer ceux qui sont inutiles et à les combiner. Vous pouvez déclencher l'opération de compression ArcSDE via ArcCatalog, configurer un service qui le fait tout le temps et certaines opérations de modification ArcMap déclencheront des opérations de mini-compression (c'est-à-dire uniquement pour les petites branches utilisées).
Le diagramme de gauche montre un arbre d'état avant qu'il ne soit compressé, et celui de droite le montre juste après sa compression:
Un concept important à comprendre (auquel je ferai référence une fois que j'aurai enfin répondu à votre question) est que chaque état est un candidat potentiel à compresser - à l'exception des États qui ont des étiquettes (c'est-à-dire des versions nommées) pointées vers eux.
Vous pouvez voir qu'avant la compression, il y a des états supplémentaires inutiles. En fait, toute la branche [3,4,5] a été supprimée. S'il y avait eu une version nommée à 5, le résultat final aurait été très différent.
Les opérations de compression sont là pour économiser de l'espace sur votre base de données en supprimant les enregistrements dont vous n'avez plus besoin.
OK, continuons.
Le dernier concept que vous devez comprendre est la réconciliation - qui consiste à fusionner efficacement deux branches en une seule.
Revenons donc à notre tout premier diagramme. Supposons que vous souhaitez réconcilier la version A avec SDE.DEFAULT.
Récapitulons: quatre versions nommées pointant vers différents identifiants d'état. Donc, la première chose que nous devons faire, c'est créer un état enfant sous la version cible, donc nous créons un état enfant sous l'état id 4, dans notre exemple, j'appelle cet état id 20.
L'étape suivante consiste à calculer les différences entre les deux versions (les détails sont trop longs pour ce post, mais je peux vous dire qu'elles sont effectuées avec des curseurs de différence ), puis à appliquer ces différences à ce nouvel identifiant d'état 20 (ligne bleue).
Supposons que vous décidiez d'effectuer plus de modifications ou que vous ayez trouvé des conflits et que vous choisissiez des lignes dans une version ou dans l'autre. Ça n'a pas d'importance. Ce ne sont que de nouvelles modifications, et sont effectuées dans une opération de modification, comme les états enfants sous la branche que vous avez fusionnée. Dans cet exemple, j'ai effectué deux autres groupes consécutifs de modifications après la réconciliation.
Charmant.
Alors maintenant, dites que vous êtes prêt à " poster " la version. Qu'est-ce que ça veut dire? C'est juste saisir les étiquettes et les pointer vers le même identifiant d'état. Ici, je vais publier la version A sur SDE.DEFAULT. Voici à quoi ça ressemble:
TADAAA! Alors maintenant, la version A et SDE.DEFAULT pointent vers le même identifiant d'état, et donc ils se ressemblent.
OK, maintenant je peux enfin répondre à votre question.
Pouvez-vous annuler un message? La documentation ArcGIS vous dira non - ne vous en faites pas. Ne le faites pas, car vous allez jouer avec cette logique, et si vous ne savez pas ce que vous faites, vous pouvez corrompre vos données.
Mais en vérité, il suffit de faire une mise à jour de l'une des tables de version d'ArcSDE - la table VERSIONS, et de modifier l'entrée de l'étiquette (alias version nommée). Dans notre exemple, pointez sur l'état id 21, et vous venez d'annuler toute l'opération d'édition. Réglez-le sur 3 et vous venez d'annuler la réconciliation entière. Réglez-le sur 5 et vous êtes maintenant dans un endroit complètement différent. Qu'il y ait ou non des conflits est sans importance.
Bien sûr, cela suppose qu'aucune compression ne s'est produite. Prenons le cas où la compression se produit exactement au même moment où vous mettez à jour la table SDE. N'oubliez pas que si vous - ou quelqu'un d'autre - exécutez une compresse après avoir posté, voici à quoi ressemble l'arborescence:
Pouvez-vous annuler la réconciliation après la compression? Eh bien, dans ce cas, non . La compresse a soufflé toute cette branche, vous ne pouvez donc pas annuler - ces données ont été supprimées. S'il y avait eu une autre version nommée sur cette branche, alors la compresse n'aurait pas détruit cette branche. J'espère que maintenant cela a du sens.
Alors, tu devrais faire ça? Selon vous, si vous ne savez pas ce que vous faites, vous pouvez facilement perdre des données après une compression.