Quando il controllo delle versioni con ArcSDE può essere cancellato o rifiutato?

Sto usando ArcGIS 9.3.1 e sto tentando di lavorare con un geodatabase SDE (con una classe di funzionalità poligono) che è già stato registrato come versione. Sono nuovo nel controllo delle versioni e sto ancora cercando di capire alcune delle sue funzioni di base. Finora non sono stato in grado di scoprire se è possibile "annullare" o "rifiutare" determinate modifiche dopo che sono state pubblicate su una versione principale.

Ad esempio, supponiamo di avere tre versioni: l'originale SDE.DEFAULT che è stato creato quando è stato registrato come versione, una versione figlio del valore predefinito denominata SDE.QA (per controllo qualità) e una versione figlio del QA chiamata SDE .Edit1 (dove avvengono per la prima volta le modifiche). Se alcune funzionalità di SDE.Edit1 fossero modificate (ad esempio, per semplificare, diciamo che è stato aggiunto un poligono e uno è stato rimosso) e quindi SDE.Edit1 è stato riconciliato con SDE.QA e successivamente pubblicato su SDE.QA, ci sarebbe essere un modo per annullare successivamente questa modifica? In seguito a questa domanda, sarebbe possibile rifiutare solo alcune modifiche? Ad esempio, accettando di aggiungere il primo poli, ma rifiutando di rimuovere il secondo poli?

Per quanto ne so, una volta che le modifiche sono state pubblicate nella versione principale, tutte queste modifiche sono ora parte "permanente" (per mancanza di una parola migliore) della versione principale. Sono consapevole del fatto che queste modifiche sono tutte registrate in due tabelle, le tabelle "ADD" e "DELETE" (spesso denominate tabelle "delta"), e in realtà non cambiano l'FC originale stesso. Ho preso in considerazione l'idea di modificare manualmente queste tabelle delta, ma ho trovato abbastanza persone che lo avvertivano per sapere che probabilmente non era la soluzione giusta.

Forse è la mia comprensione del controllo delle versioni che richiede un po 'di lavoro, ma non riesco a trovare un modo per rifiutare una modifica o annullare una modifica una volta che è stata pubblicata. Mi sembra strano, poiché ciò significherebbe che non c'è modo di annullare un post che conteneva un errore. Inoltre, non riesco a trovare un modo per tracciare il lignaggio di queste versioni (cioè, quale versione è figlia di quale genitore). Mentre sono sull'argomento, se qualcuno potesse conoscere riferimenti ArcSDE particolarmente utili (link, articoli, libri, ecc.) Che potrebbero aiutarmi a comprendere ArcSDE (e forse rispondere ad alcune di queste domande), sarebbe molto apprezzato !

Sebbene le risposte finora siano state utili (grazie per i collegamenti), non riesco ancora a trovare una risposta al nocciolo della mia domanda. Ancora una volta, forse è il mio malinteso sulla situazione. Ecco cosa voglio sapere:

Puoi invertire (al contrario, intendo annullare ) un post una volta che è stato fatto da una versione figlio a una versione principale? In questo scenario, il genitore può essere, ma non deve essere, la versione SDE.DEFAULT. Ancora meglio, vorrei sapere se è possibile invertire una parte di un post (ad esempio una singola modifica in un poligono), dopo che è stato pubblicato? Vorrei anche sapere se ciò può essere fatto senza che sia stato rilevato alcun conflitto.

Il fatto che non riesca a trovare una risposta chiara a questa domanda (ovvero "sì" o "no") documentata ovunque mi fa pensare che mi manca qualcosa di importante sul controllo delle versioni in ArcSDE. Preferirei anche evitare di manipolare manualmente le tabelle A e D.

Ugh. La risposta è davvero complicata e richiede molto background in ArcSDE, quindi cercherò di essere il più breve possibile.

Nota Farò riferimento ad alcuni diagrammi del fantastico white versioning che puoi trovare nel sito ESRI . Se hai a che fare con il controllo delle versioni, ti incoraggio a leggere attentamente.

Quindi, è necessario comprendere qual è la relazione tra uno stato (ovvero un nodo dall'albero degli stati) e una versione denominata (ovvero un'etichetta che punta a uno stato).

Un database tipico può apparire come il diagramma di stato seguente:

Qui, hai quattro versioni nel database (Versione A, Versione B, Versione C e DEFAULT). Ma forse, mi sto un po 'anticipando. Cominciamo con cos'è uno stato .

Puoi considerare uno stato come una "transazione" - un'unità logica che contiene diverse modifiche a una o più tabelle. Può includere due inserti in "FeatureClass A", un'eliminazione da "Feature Class B" e una modifica (in effetti un'eliminazione + un insert) in "Feature Class X". Tutti raggruppati in uno.

Diamo un'occhiata a un piccolo, semplice diagramma di stato ArcSDE che inizia con lo stato ID 0:

Se si avvia allo stato 0 e si apportano modifiche a una o più tabelle in un'operazione di modifica, verrà creato uno stato figlio 1 e lo si trasformerà nell'ID stato attivo corrente . Un altro gruppo di modifiche successivo creerà lo stato figlio 2. Se si desidera annullare, non è necessario modificare l'ID stato in alcun modo: tutto ciò che occorre fare è modificare l'ID stato attivo corrente su 1 o 0 (a seconda quanto lontano vuoi andare). Una ripetizione è l'opposto: basta spostare in avanti l'ID dello stato attivo corrente, il più avanti possibile.

Ecco come funziona annulla / ripristina nel controllo delle versioni di ArcSDE.

OK, andiamo avanti. Supponiamo che tu voglia rendere permanente una modifica (ovvero, vuoi salvare). Cosa devi fare? Bene, il salvataggio è solo afferrare un'etichetta di versione e spostarla in avanti verso uno stato particolare. Un po 'come timbrarlo e dire "questo è l'aspetto della versione A". Quindi, se guardi indietro al primo diagramma, vedrai che ha quattro versioni con nome .

• La versione B indica lo stato 1
• La versione A indica lo stato 3
• La versione C indica lo stato 5

• La versione "SDE.DEFAULT" punta all'ID stato 4

  Si noti che questo diagramma, nonostante la credenza popolare, non ti dice nulla sulla logica relazione genitore-figlio che hanno. La relazione logica padre-figlio per il primo diagramma potrebbe apparire in questo modo efficace:

Questa è la relazione padre-figlio che vedi in ArcMap / ArcCatalog. Lo scopo è limitare le versioni con cui è possibile riconciliare. A questo punto, potresti (giustamente) chiederti, perché diavolo ho bisogno di questo? La risposta sta nei flussi di lavoro di versioning . A quanto pare, le persone usano il controllo delle versioni da un po 'di tempo e ci sono alcuni modi preferiti di strutturarli, ma questo è un argomento per un altro giorno da quando voglio rispondere alla tua domanda oggi :)

Andare avanti...

OK, cos'altro fanno queste versioni nominate? Bene, influenzano il comportamento di questo processo chiamato comprimere .

Comprimere significa afferrare gli stati intermedi che potrebbero non essere necessari e rimuovere quelli non necessari e combinarli. È possibile attivare l'operazione di compressione ArcSDE tramite ArcCatalog, impostare un servizio che lo fa ogni tanto e alcune operazioni di modifica di ArcMap attiveranno operazioni di mini-compressione (vale a dire solo per piccoli rami che vengono utilizzati).

Il diagramma a sinistra mostra un albero di stato prima che venga compresso e quello a destra lo mostra subito dopo che è stato compresso:

Un concetto importante da comprendere (che farò riferimento a te quando finalmente riuscirò a rispondere alla tua domanda) è che ogni singolo stato è un potenziale candidato da comprimere - tranne gli stati che hanno etichette (cioè versioni denominate) puntate su di loro.

Puoi vedere che prima della compressione ci sono alcuni stati extra - non necessari. In effetti, l'intero ramo [3,4,5] è stato rimosso. Se ci fosse stata una versione nominata a 5, il risultato finale sarebbe stato molto diverso.

Le operazioni di compressione sono lì per risparmiare spazio sul database rimuovendo i record non più necessari.

OK, andiamo avanti.

L'ultimo concetto che devi capire è la riconciliazione , che sta effettivamente fondendo due rami in uno.

Quindi torniamo al nostro primo diagramma. Supponi di voler riconciliare la versione A con SDE.DEFAULT.

Ricapitoliamo: quattro versioni nominate che puntano a vari ID di stato. Quindi la prima cosa che dobbiamo fare è creare uno stato figlio nella versione di destinazione, quindi creiamo uno stato figlio con lo stato ID 4, nel nostro esempio, chiamo tale stato ID 20.

Il prossimo passo è calcolare le differenze tra le due versioni (i dettagli sono troppo lunghi per questo post, ma posso dirti che sono stati fatti con i cursori delle differenze ) e quindi applicare quelle differenze a quel nuovo ID di stato 20 (linea blu).

Supponi che decidi di apportare più modifiche o di aver trovato conflitti e di scegliere le righe da una versione o dall'altra. Non importa Queste sono solo nuove modifiche e vengono eseguite all'interno di un'operazione di modifica, come afferma figlio sotto il ramo che hai unito. In questo esempio, ho eseguito altri due gruppi consecutivi di modifiche dopo la riconciliazione.

Bello.

Quindi ora dì che sei pronto per " pubblicare " la versione. Cosa significa? Questo è solo afferrare le etichette e indicarle allo stesso ID di stato. Qui, pubblicherò la versione A su SDE.DEFAULT. Ecco come appare:

TADAAA! Quindi ora la versione A e SDE.DEFAULT puntano allo stesso ID di stato e quindi sembrano uguali.

OK, ora posso finalmente rispondere alla tua domanda.

Puoi annullare un post? La documentazione di ArcGIS ti dirà di no - non scherzare con esso. Non farlo, perché ti sbaglierai con questa logica e se non sai cosa stai facendo, puoi corrompere i tuoi dati.

Ma in realtà, tutto ciò che serve è fare un aggiornamento di una delle tabelle di Versioning di ArcSDE - la tabella VERSIONS e modificare la voce dell'etichetta (nota anche come versione denominata). Nel nostro esempio, indica lo stato 21 e hai appena annullato l'intera operazione di modifica. Impostalo su 3 e hai appena annullato la riconciliazione. Impostalo su 5 e ora ti trovi in ​​un posto completamente diverso. Se ci sono o non ci sono conflitti è irrilevante.

Ovviamente, ciò presuppone che non si sia verificato un impacco. Consideriamo il caso in cui la compressione sta avvenendo esattamente nello stesso momento in cui si aggiorna la tabella SDE. Ricorda, se tu o qualcun altro esegui un impacco dopo aver pubblicato questo è l'aspetto dell'albero:

Puoi annullare la riconciliazione dopo la compressione? Bene, in questo caso, no . La compressione ha spazzato via l'intero ramo, quindi non è possibile annullare: quei dati sono stati rimossi. Se ci fosse stata un'altra versione denominata su quel ramo, la compressione non avrebbe distrutto quel ramo. Spero che ormai abbia senso.

Quindi dovresti farlo? A te, se non sai cosa stai facendo, puoi facilmente perdere dati dopo un impacco.

Esiste uno strumento chiamato Geodatabase Toolset (GDBT), che è un plug-in per ArcCatalog. Visualizza il linage e le versioni di stato:

Scarica GDBT qui

A corto di conoscere la versione e il db. ecco alcune informazioni iniziali che ti aiuteranno.
Admin di base
Ecco alcune informazioni su rec e post
Quindi, se si applicano questi concetti e si utilizza il comando di modifica delle versioni, si ha ancora la possibilità di rifiutare tali modifiche quando si registra e si pubblica come predefinito.

Non hai tre copie dello stesso database.
Ne hai una copia con le versioni.
Se stai gestendo questo db, dovresti davvero passare il tempo (forse anche i soldi) e prendere confidenza con tutto questo.
La classe esri Flussi di lavoro di modifica della versione per il geodatabase multiutente è gratuita e aiuterà alcuni.
Ma il monte completo sarebbe quello che consiglio a una persona che amministra qualsiasi tipo di flusso di lavoro di modifica delle versioni sde.
Quella lezione è fantastica! per la comprensione dei flussi di lavoro di modifica delle versioni per il geodatabase multiutente .

Ho un modo "veloce e sporco". Passa alla versione predefinita e modifica qualcosa sul poligono che è stato eliminato. Quindi, quando ti riconcili con il valore predefinito, otterrai un conflitto. Fare clic con il tasto destro del mouse sul conflitto e comunicargli di utilizzare lo stato di pre-riconciliazione. Per me funziona.

Sì, potresti farlo, ma dovrai farlo usando SQL.

NON CONDIZIONO QUESTO, FACCIO A VOSTRO RISCHIO PROPRIO. SEMPRE IL backup dei dati prima di modificare manualmente SDE.

È possibile eseguire una query sulla tabella sde.versions per ottenere state_id dalla versione pubblicata con le modifiche che si desidera annullare. Quindi puoi andare alle tabelle A e D ed eliminare le voci che corrispondono a state_id.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Ora hai il state_id di interesse. Ora devi trovare le tabelle A e D per la classe di entità geografiche. Puoi farlo interrogando table_registry. Il valore sarà il registration_id. Quindi per ottenere le tabelle A e D, basta aggiungere il registration_id alle A e D.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

Quindi basta eseguire una query su entrambe le tabelle A e D ed eliminare le voci che hanno lo stato_ID dalla query precedente.

Per saperne di più sulle relazioni padre e figlio, basta fare una query dalle seguenti tabelle sde.

    state_lineages
    versions
    states

Tutti questi hanno relazioni e dovrebbero aiutarti a seguire la palla che rimbalza.

Non è possibile annullare le modifiche dopo che sono state pubblicate da una versione figlio alla versione principale. Vedi: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

L'operazione post non può essere annullata, poiché stai applicando le modifiche a una versione che non stai modificando.

Puoi rivedere le modifiche apportate in ciascuna versione durante il processo di riconciliazione: questa sarebbe la tua possibilità di rifiutare determinate modifiche. Il processo di riconciliazione è spiegato qui .

Sì, come altri hanno già detto, la risposta breve è no.

Il versioning di SDE è così promettente, ma è un peccato che il suo flusso di lavoro presupponga solo cambiamenti diretti nelle funzionalità.

Il versioning completo in SDE offrirebbe strumenti che-

• Consente il rollback (a livello di funzionalità) e accetta / rifiuta
• Consentirebbe annullamenti
• E consentirebbe annullamenti di stati precedenti (ovvero partendo da stat 3, annullando le modifiche dallo stato 1 ma mantenendo le modifiche dallo stato 2).

Questo sarebbe come un sistema di controllo delle versioni del codice sorgente SVN, ma per le funzioni spaziali.

La semplice risposta è NO.

L'intenzione di pubblicare una versione è di eseguire il commit di tali modifiche nella versione di destinazione.

Il rollback si ottiene non pubblicando la versione (ed è buona norma eliminare tali versioni abbandonate).

Durante la modifica della versione, l'applicazione di modifica (ad esempio ArcMap) può fornire vari livelli di "annullamento" e l'utente può scegliere di salvare / non salvare tali modifiche nella versione che si sta modificando.

Ma dopo la pubblicazione su un target (ad es. Sde.default) l'unico modo per annullare è tramite gli hack alle tabelle di sistema sde.