Kiedy wersjonowanie za pomocą ArcSDE może zostać anulowane lub odrzucone, wprowadzone zmiany?

Korzystam z ArcGIS 9.3.1 i próbuję pracować z geobazą SDE (z jedną klasą obiektów wielokąta), która została już zarejestrowana jako wersja. Jestem nowy w wersjonowaniu i wciąż próbuję rozgryźć niektóre z jego podstawowych funkcji. Jak dotąd nie udało mi się ustalić, czy można „anulować” lub „odrzucić” niektóre zmiany po opublikowaniu ich w wersji nadrzędnej.

Załóżmy na przykład, że mamy trzy wersje: oryginalną SDE.DEFAULT, która została utworzona, gdy została zarejestrowana jako wersjonowana, wersję podrzędną domyślnej o nazwie SDE.QA (dla zapewnienia jakości) oraz wersję podrzędną kontroli jakości o nazwie SDE .Edycja 1 (gdzie najpierw mają miejsce zmiany). Gdyby niektóre funkcje SDE.Edit1 były edytowane (np. Dla uproszczenia, powiedzmy, że jeden wielokąt został dodany, a jeden usunięty), a następnie SDE.Edit1 zostałby uzgodniony z SDE.QA, a następnie wysłany do SDE.QA, czy byłby być w jakiś sposób później cofnąć tę zmianę? Czy w następstwie tego pytania można odrzucić tylko niektóre zmiany? Na przykład akceptujesz dodanie pierwszego poli, ale odrzucasz usunięcie drugiego poli?

O ile wiem, po opublikowaniu zmian w wersji nadrzędnej, wszystkie te zmiany są teraz „trwałą” (z braku lepszego słowa) częścią wersji nadrzędnej. Wiem, że wszystkie te zmiany są rejestrowane w dwóch tabelach, tabelach „DODAJ” i „USUŃ” (często nazywanych tabelami „delta”), i tak naprawdę nie zmieniają samego oryginalnego FC. Zastanawiałem się nad ręcznym zmodyfikowaniem tych tabel delta, ale znalazłem wystarczającą liczbę osób ostrzegających przed tym, aby wiedzieć, że prawdopodobnie nie jest to właściwe rozwiązanie.

Być może to moje rozumienie wersji wymaga trochę pracy, ale nie mogłem znaleźć sposobu na odrzucenie zmiany lub cofnięcie zmiany po jej opublikowaniu. Wydaje mi się to dziwne, ponieważ oznaczałoby to, że nie ma możliwości cofnięcia postu zawierającego błąd. Nie mogę również znaleźć sposobu na prześledzenie pochodzenia tych wersji (tj. Która wersja jest dzieckiem danego rodzica). Będąc na ten temat, jeśli ktokolwiek mógłby wiedzieć o szczególnie użytecznych odnośnikach do ArcSDE (linki, artykuły, książki itp.), Które mogłyby pomóc w moim zrozumieniu ArcSDE (i być może odpowiedzieć na niektóre z tych pytań), byłoby bardzo mile widziane !

Jak dotąd odpowiedzi były pomocne (dziękuję za linki), ale nadal nie mogę znaleźć odpowiedzi na rdzeń mojego pytania. Ponownie, być może jest to moje własne niezrozumienie sytuacji. Oto, co chcę wiedzieć:

Czy możesz cofnąć (przez cofnięcie, mam na myśli cofnięcie ) post, który został utworzony z wersji podrzędnej do wersji nadrzędnej? W tym scenariuszu rodzicem może być, ale nie musi, wersja SDE.DEFAULT. Co więcej, chciałbym wiedzieć, czy możesz zamienić część postu (powiedzmy, pojedynczą edycję na wielokąt) po jego opublikowaniu? Chciałbym również wiedzieć, czy można tego dokonać bez konieczności wykrycia jakichkolwiek konfliktów.

Fakt, że nie mogę nigdzie znaleźć jednoznacznej odpowiedzi na to pytanie (tj. „Tak” lub „nie”), sprawia, że ​​myślę, że brakuje mi czegoś ważnego na temat wersji w ArcSDE. Wolałbym również unikać ręcznego manipulowania tabelami A i D.

Ugh. Odpowiedź jest naprawdę skomplikowana i wymaga dużo tła ArcSDE, więc postaram się być jak najkrócej.

Uwaga Odwołam się do niektórych diagramów z super niesamowitej białej księgi wersji, którą można znaleźć na stronie ESRI . Jeśli masz do czynienia z wersjonowaniem, bardzo zachęcam do lektury.

Następnie musisz zrozumieć, jaki jest związek między stanem (tj. Węzłem z drzewa stanów) a nazwaną wersją (tj. Etykietą wskazującą na stan).

Typowa baza danych może wyglądać jak na poniższym diagramie stanu:

Tutaj masz cztery wersje w bazie danych (wersja A, wersja B, wersja C i DOMYŚLNE). Ale może trochę wyprzedzam. Zacznijmy od stanu .

Możesz myśleć o stanie jak o „transakcji” - logicznej jednostce, która zawiera kilka edycji jednej lub wielu tabel. Może zawierać dwie wstawki do „FeatureClass A”, usunięcie z „Feature Class B” i modyfikację (w rzeczywistości usunięcie + insert) do „Feature Class X”. Wszystko zgrupowane w jednym.

Spójrzmy na mały, prosty diagram stanu ArcSDE, który zaczyna się od stanu id 0:

Jeśli zaczniesz od stanu 0 i dokonasz edycji jednej lub wielu tabel w operacji edycji, utworzysz stan podrzędny 1 i uczynisz go bieżącym identyfikatorem stanu aktywnego . Kolejna kolejna grupa edycji utworzy stan podrzędny 2. Jeśli chcesz cofnąć, nie musisz w żaden sposób modyfikować identyfikatora stanu - wystarczy zmienić bieżący stan aktywnego identyfikatora na 1 lub 0 (w zależności jak daleko chcesz się cofnąć). Ponowienie jest odwrotne - wystarczy przesunąć bieżący identyfikator aktywnego stanu do przodu - tak daleko, jak chcesz.

Tak działa cofanie / ponawianie w wersjach ArcSDE.

OK, idziemy dalej. Powiedz, że chcesz zrobić edycję na stałe (tzn. Chcesz zapisać). Co masz do zrobienia? Oszczędność polega tylko na pobraniu etykiety wersji i przeniesieniu jej do określonego stanu. Coś w rodzaju wytłoczenia go i powiedzenia „tak musi wyglądać wersja A”. Więc jeśli spojrzysz wstecz na pierwszy schemat, zobaczysz, że ma on cztery nazwane wersje .

• Wersja B wskazuje na stan id 1
• Wersja A wskazuje na stan id 3
• Wersja C wskazuje na stan id 5

• Wersja „SDE.DEFAULT” wskazuje na stan id 4

  Pamiętaj, że ten schemat, pomimo powszechnego przekonania, nie mówi ci nic o logicznej relacji rodzic-dziecko. Logiczna relacja rodzic-dziecko dla pierwszego diagramu może wyglądać tak:

Jest to relacja rodzic-dziecko widoczna w ArcMap / ArcCatalog. Jego celem jest ograniczenie wersji, z którymi można się pogodzić. W tym momencie możesz (słusznie) zadać sobie pytanie, dlaczego, do diabła, potrzebuję tego? Odpowiedź leży w przepływie pracy wersji . Okazuje się, że ludzie używają wersjonowania już od dłuższego czasu i istnieją pewne preferowane sposoby ich strukturyzacji, ale to temat na kolejny dzień, ponieważ chcę dziś odpowiedzieć na twoje pytanie :)

Iść dalej...

OK, więc co jeszcze robią te nazwane wersje? Wpływają na to, jak zachowuje się ten proces zwany kompresją .

Kompresja polega na przechwytywaniu stanów pośrednich, które mogą nie być konieczne, usuwaniu niepotrzebnych oraz łączeniu ich. Możesz uruchomić operację kompresji ArcSDE poprzez ArcCatalog, skonfigurować usługę, która robi to co jakiś czas, a niektóre operacje edycji ArcMap wyzwalają operacje mini-kompresji (tj. Tylko w przypadku małych oddziałów, które są używane).

Schemat po lewej pokazuje drzewo stanu przed jego skompresowaniem, a ten po prawej pokazuje je zaraz po skompresowaniu:

Ważną koncepcją, którą należy zrozumieć (do której odniosę się, gdy w końcu będę mógł odpowiedzieć na twoje pytanie), jest to, że każdy stan jest potencjalnym kandydatem do skompresowania - z wyjątkiem stanów, które wskazują na nie etykiety (tj. Nazwane wersje).

Widać, że przed kompresem występują dodatkowe - niepotrzebne stany. W rzeczywistości cała gałąź [3,4,5] została usunięta. Gdyby istniała nazwana wersja na 5, wynik końcowy byłby zupełnie inny.

Operacje kompresji pozwalają zaoszczędzić miejsce w bazie danych poprzez usunięcie rekordów, których już nie potrzebujesz.

OK, idziemy dalej.

Ostatnią koncepcją, którą musisz zrozumieć, jest uzgadnianie - które skutecznie łączy dwie gałęzie w jedną.

Wróćmy więc do naszego pierwszego schematu. Powiedz, że chcesz pogodzić wersję A z SDE.DEFAULT.

Podsumujmy: cztery nazwane wersje wskazujące na różne identyfikatory stanu. Pierwszą rzeczą, którą musimy zrobić, jest utworzenie stanu potomnego pod wersją docelową, więc tworzymy stan potomny pod stanem id 4, w naszym przykładzie nazywam ten stan id 20.

Następnym krokiem jest obliczenie różnic między obiema wersjami (szczegóły są za długie dla tego postu, ale mogę powiedzieć, że zostały one wykonane za pomocą kursorów różnic ), a następnie zastosowanie tych różnic do tego nowego stanu id 20 (niebieska linia).

Powiedz, że decydujesz się na więcej edycji lub znalazłeś konflikty i wybierasz wiersze z jednej lub drugiej wersji. To nie ma znaczenia Są to tylko nowe edycje, które są wykonywane w ramach operacji edycji, jak stwierdza dziecko pod gałęzią, którą scaliłeś. W tym przykładzie wykonałem dwie kolejne grupy zmian po uzgodnieniu.

Śliczny.

Więc teraz powiedz, że jesteś gotowy „ opublikuj ” wersję. Co to znaczy? To tylko chwytanie etykiet i kierowanie ich do tego samego identyfikatora stanu. Tutaj zamierzam opublikować wersję A na SDE.DEFAULT. Tak to wygląda:

TADAAA! Więc teraz wersja A i SDE.DEFAULT wskazują na ten sam identyfikator stanu, a zatem wyglądają tak samo.

OK, teraz mogę w końcu odpowiedzieć na twoje pytanie.

Czy możesz cofnąć post? Dokumentacja ArcGIS powie ci nie - nie zadzieraj z tym. Nie rób tego, ponieważ będziesz bałaganić tą logiką, a jeśli nie wiesz, co robisz, możesz uszkodzić swoje dane.

Ale tak naprawdę wystarczy wykonać jedną aktualizację jednej z tabel Wersji ArcSDE - tabeli VERSIONS i zmodyfikować wpis etykiety (zwanej także wersją nazwaną). W naszym przykładzie wskaż stan 21, a właśnie cofnąłeś całą operację edycji. Ustaw na 3, a ty po prostu cofniesz cały pogodzenie. Ustaw na 5, a teraz jesteś w zupełnie innym miejscu. To, czy są konflikty, czy nie, nie ma znaczenia.

Oczywiście zakłada to, że kompres nie nastąpił. Rozważmy przypadek, w którym kompres odbywa się dokładnie w momencie aktualizacji tabeli SDE. Pamiętaj, że jeśli ty lub ktoś inny wykonuje kompres po opublikowaniu, drzewo wygląda następująco:

Czy można cofnąć uzgodnienie po kompresie? Cóż, w tym przypadku nie . Kompres zdmuchnął całą gałąź, więc nie można cofnąć - dane zostały usunięte. Gdyby w tej gałęzi była inna nazwana wersja, kompres nie zniszczyłby tej gałęzi. Mam nadzieję, że do tej pory ma to sens.

Więc powinieneś to zrobić? Jeśli nie wiesz, co robisz, możesz samodzielnie stracić dane po kompresji.

Istnieje narzędzie o nazwie Geodatabase Toolset (GDBT), które jest wtyczką do ArcCatalog. Wizualizuje linię stanu i wersje:

Pobierz GDBT tutaj

Brak znajomości wersji i db. oto kilka wstępnych informacji, które ci pomogą.
Podstawowy administrator
Oto kilka informacji na temat nagrywania i publikowania.
Jeśli zastosujesz te koncepcje i użyjesz polecenia zmiany wersji , nadal będziesz mieć możliwość odrzucenia tych zmian podczas zapisywania i publikowania ustawień domyślnych.

Nie masz trzech kopii tej samej bazy danych.
Masz jedną kopię z wersjami.
Jeśli administrujesz tą bazą danych, naprawdę powinieneś spędzić czas (może nawet pieniądze) i zapoznać się z tym wszystkim.
ESRI klasa wersjonowanym Montaż Workflows dla wielu użytkowników geobazie jest bezpłatna i pomóc niektórym.
Ale pełny monte byłby tym, co polecam osobie administrującej dowolnym rodzajem pracy z edycją sde.
Ta klasa jest świetna! do zrozumienia przepływów pracy edycji wersji dla geobazy dla wielu użytkowników .

Mam „szybki i brudny” sposób. Przejdź do domyślnej wersji i edytuj coś o usuniętym wielokącie. Następnie, gdy dojdziesz do domyślnych ustawień, pojawi się konflikt. Kliknij konflikt prawym przyciskiem myszy i powiedz mu, aby użył stanu wstępnego uzgadniania. Mi to pasuje.

Tak, możesz to zrobić, ale będziesz musiał to zrobić za pomocą SQL.

NIE ZAPEWNIAMY TEGO, ZRÓB TO NA WŁASNE RYZYKO. ZAWSZE ZAPASUJ SWOJE DANE PRZED EDYCJĄ SDE RĘCZNIE.

Możesz wysłać zapytanie do tabeli sde.versions, aby uzyskać identyfikator_stanu z opublikowanej wersji ze zmianami, które chcesz cofnąć. Następnie możesz przejść do tabel A i D i usunąć wpisy, które pasują do id_stanu.

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

Teraz masz interesujący Cię status_id. Teraz musisz znaleźć tabele A i D dla klasy elementów. Robisz to, wysyłając zapytanie do table_registry. Wartością będzie identyfikator_rejestracji. Aby uzyskać tabele A i D, wystarczy dodać identyfikator rejestracji do A i D.

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

Następnie po prostu zapytaj tabelę A i D i usuń wpisy, które mają identyfikator_stanu z powyższego zapytania.

Aby dowiedzieć się więcej o relacjach nadrzędnych i podrzędnych, po prostu zapytaj z poniższych tabel sde.

    state_lineages
    versions
    states

Wszystkie one mają relacje i powinny pomóc ci podążać za odbijającą się piłką.

Nie można cofnąć edycji po opublikowaniu jej z wersji podrzędnej do wersji nadrzędnej. Zobacz: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

Operacji wysyłania nie można cofnąć, ponieważ wprowadzasz zmiany do wersji, której aktualnie nie edytujesz.

Możesz przejrzeć zmiany wprowadzone w każdej wersji podczas procesu uzgadniania - to byłaby Twoja szansa na odrzucenie niektórych zmian. Proces uzgadniania wyjaśniono tutaj .

Tak, jak powiedzieli inni, krótka odpowiedź brzmi „nie”.

Wersjonowanie SDE jest tak obiecujące, ale niefortunne jest to, że jego przepływ pracy zakłada jedynie zmianę funkcji w przód.

W pełni funkcjonalna wersja w SDE oferuje narzędzia, które-

• Umożliwia wycofanie (na poziomie funkcji) i akceptowanie / odrzucanie
• Pozwoliłoby cofać
• Pozwoliłby cofnąć poprzednie stany (tj. Począwszy od statystyki 3, cofnąć zmiany ze stanu 1, ale zachować zmiany ze stanu 2).

To byłoby jak system kontroli wersji kodu źródłowego SVN, ale dla funkcji przestrzennych.

Prostą odpowiedzią jest: nie.

Zamiarem opublikowania wersji jest zatwierdzenie tych zmian w wersji docelowej.

Cofanie jest realizowane przez nie publikowanie wersji (i dobrą praktyką jest usuwanie takich opuszczonych wersji).

Podczas edycji wersji aplikacja do edycji (na przykład ArcMap) może zapewniać różne poziomy „cofania”, a użytkownik może wybrać zapisanie / nie zapisanie takich edycji w edytowanej wersji.

Ale po wysłaniu do celu (np. Sde.default) jedynym sposobem na cofnięcie jest włamanie do tabel systemowych sde.