Коли Версія з ArcSDE може опубліковані зміни скасовувати чи відхиляти?

Я використовую ArcGIS 9.3.1 і намагаюся працювати з базою геодезичних даних SDE (з одним класом характеристик багатокутника), яка вже була зареєстрована як версія. Я новачок у версії та все ще намагаюся з’ясувати деякі його основні функції. Поки що я не зміг виявити, чи можна "скасувати" або "відхилити" певні зміни після їх публікації в батьківській версії.

Наприклад, скажімо, у нас є три версії: оригінальний SDE.DEFAULT, який був створений, коли він був зареєстрований як версія, дочірня версія за замовчуванням, що називається SDE.QA (для забезпечення якості), і дочірня версія QA під назвою SDE .Edit1 (де вперше відбуваються зміни). Якщо певні особливості SDE.Edit1 були відредаговані (наприклад, щоб зробити це просто, скажімо, додали один багатокутник і видалили), а потім SDE.Edit1 узгодився з SDE.QA і згодом був розміщений на SDE.QA, будь-який спосіб пізніше скасувати цю зміну? Після цього питання, чи можна було б відхилити лише деякі зміни? Наприклад, приймаючи додавання першого полі, але відхиляючи видалення другого полі?

Наскільки я можу сказати, після редагування в батьківській версії всі ці зміни тепер є "постійною" (за відсутністю кращого слова) частиною батьківської версії. Мені відомо про те, що ці зміни реєструються в двох таблицях, "ADD" і "DELETE" (часто їх називають "delta") і фактично не змінюють оригінальний FC. Я розглядав можливість змінити вручну зміни цих таблиць дельти, але знайшов достатньо людей, які попереджають це, щоб знати, що це, мабуть, не правильне рішення.

Можливо, саме моє розуміння версії потребує певної роботи, але я, здається, не можу знайти спосіб відхилити зміни або скасувати зміну після її розміщення. Мені це здається дивним, оскільки це означатиме, що немає можливості скасувати публікацію, яка містила помилку. Я також не можу знайти спосіб простежити походження цих версій (тобто, яка версія дочірнього батька). Хоча я на тему, якщо хтось може знати будь-які особливо корисні посилання на ArcSDE (посилання, статті, книги тощо), які можуть допомогти в моєму розумінні ArcSDE (і, можливо, відповісти на деякі з цих питань), було б дуже вдячно !

Хоча відповіді досі були корисними (дякую за посилання), я все ще не можу знайти відповідь до основи мого питання. Знову ж таки, можливо, це моє власне нерозуміння ситуації. Ось що я хочу знати:

Чи можете ви скасувати (зворотним, я маю на увазі скасування ) публікації, коли вона була зроблена з дочірньої версії до батьківської версії? У цьому випадку батько може бути, але не обов’язково, версією SDE.DEFAULT. Ще краще, я хотів би знати, чи можете ви змінити частину публікації (скажімо, одну редагування на багатокутник) після її опублікування? Я також хотів би знати, чи можна це зробити без необхідності виявлення конфліктів.

Той факт, що я не можу знайти чіткої відповіді на це запитання (тобто "так" чи "ні"), зафіксованого будь-де, змушує мене думати, що я пропускаю щось важливе щодо версій в ArcSDE. Я також вважаю за краще уникати маніпулювання таблицями A і D вручну.

Тьфу. Відповідь справді складна, що вимагає багато ArcSDE фону, тому я постараюся бути якомога коротшим.

Примітка. Я звернусь до деяких діаграм із надзвичайного білого паперу для версій, який ви можете знайти на веб-сайті ESRI . Якщо ви маєте справу з версіями, я настійно рекомендую вам це прочитати.

Потім вам потрібно зрозуміти, яка взаємозв'язок між станом (тобто вузлом із дерева стану) та названою версією (тобто міткою, що вказує на стан).

Типова база даних може виглядати як діаграма стану нижче:

Тут у базі даних є чотири версії (Версія A, Версія B, Версія C та DEFAULT). Але, можливо, я трохи випереджаю себе. Почнемо з того, що таке держава .

Ви можете думати про стан як про "транзакцію" - логічну одиницю, яка містить кілька змін до однієї - або багатьох - таблиць. Він може включати дві вставки до "FeatureClass A", видалення з "Класу особливостей B" та зміну (фактично видалення + вставка) на "Клас особливості X". Всі згруповані в одне ціле.

Давайте розглянемо невелику, просту діаграму стану ArcSDE, яка починається з ідентифікатора стану 0:

Якщо ви починаєте з стану 0 і ви редагуєте одну або декілька таблиць під час операції редагування, ви створите дочірній стан 1 і зробите для цього поточний ідентифікатор активного стану . Наступна група редагувань створить дочірній стан 2. Якщо ви хочете скасувати скасування, вам не потрібно жодним чином змінювати ідентифікатор стану - все, що вам потрібно зробити, це змінити поточний ідентифікатор активного стану на 1 або 0 (залежно як далеко ти хочеш піти). Повтор - це навпаки - просто перемістіть поточний ідентифікатор активного стану вперед - настільки далеко, як ви хочете піти.

Ось як працює скасування / повторення у версії ArcSDE.

Гаразд, рухаємось далі. Скажіть, що ви хочете зробити редагування постійним (тобто, ви хочете зберегти). Що ти маєш зробити? Ну, заощадження - це просто захопити мітку версії та перенести її вперед до певного стану. Вигляд ніби відбиває її штампом і каже: "Ось як має виглядати Версія А". Тож якщо ви оглянетеся на першу діаграму, то побачите, що вона має чотири названі версії .

• Версія B вказує на ідентифікатор стану 1
• Версія A вказує на стан id 3
• Версія C вказує на ідентифікатор стану 5

• Версія "SDE.DEFAULT" вказує на ідентифікатор стану 4

  Зверніть увагу , що ця схема, незважаючи на поширену думку, не говорить вам нічого про логічних відносинах батько-дитина , що у них є. Логічні відносини батько-дитина для першої діаграми можуть виглядати так:

Це стосунки батько-дитина, які ви бачите в ArcMap / ArcCatalog. Його мета полягає в обмеженні версій, з якими можна узгодити. У цей момент ви могли (по праву) запитати себе, навіщо, чортве, мені це потрібно? Відповідь полягає у версії робочих процесів . Виявляється, люди користуються версіями вже досить давно, і є декілька бажаних способів їх структурування, але це тема для іншого дня, оскільки я хочу відповісти на ваше запитання сьогодні :)

Жити далі...

Гаразд, і що ще роблять ці названі версії? Ну, вони впливають на те, як поводиться цей процес, який називається компресом .

Стиснення полягає в захопленні проміжних станів, які можуть не знадобитися, та видаленні зайвих, а також їх поєднанні. Ви можете запустити операцію стиснення ArcSDE через ArcCatalog, налаштувати службу, яка робить це кожного за деякий час, а деякі операції редагування ArcMap запускають операції міні-стиснення (тобто лише для невеликих гілок, які використовуються).

Діаграма зліва показує дерево стану перед тим, як воно стискається, а те, що знаходиться праворуч, показує його право після стиснення:

Важлива концепція, яку потрібно зрозуміти (до якої я звернуся, як тільки я нарешті дістану відповідь на ваше запитання), - це те, що кожен штат є потенційним кандидатом для стиснення - за винятком станів, на яких вказані мітки (тобто названі версії).

Ви можете бачити, що перед стисненням є кілька зайвих - непотрібних станів. Насправді всю [3,4,5] гілку видалили. Якби в 5 була названа версія, кінцевий результат був би зовсім іншим.

Операції стиснення існують для економії місця у вашій базі даних, видаляючи записи, які вам більше не потрібні.

Гаразд, рухаємось далі.

Остання концепція, яку потрібно зрозуміти, - це узгодження - це ефективно злиття двох гілок в одну.

Тому повернемося до нашої найпершої діаграми. Скажіть, що ви хочете узгодити Версію A з SDE.DEFAULT.

Давайте резюмуємо: чотири названі версії, що вказують на різні ідентифікатори стану. Отже, перше, що нам потрібно зробити, - це створити дочірню державу під цільовою версією, тому ми створимо дочірню державу під станом id 4, у нашому прикладі я називаю цей стан id 20.

Наступним кроком є ​​підрахунок різниць між обома версіями (деталі занадто довгі для цієї посади, але я можу сказати вам, що вони зроблені з курсорами різниці ), а потім застосувати ці відмінності до цього нового стану id 20 (синя лінія).

Скажіть, що ви вирішили зробити більше змін, або що ви знайшли конфлікти і вибираєте рядки з однієї чи іншої версії. Це не має значення. Це лише нові редагування, які виконуються в межах операції редагування, як дочірня заявка під гілкою, яку ви об’єднали. У цьому прикладі я здійснив ще дві послідовні групи змін після примирення.

Прекрасна.

Тому зараз скажіть, що ви готові " опублікувати " версію. Що це означає? Це просто захопити мітки та вказати їх на той самий ідентифікатор стану. Тут я збираюся опублікувати Версію A на SDE.DEFAULT. Ось як це виглядає:

ТАДААА! Отже, версії A і SDE.DEFAULT вказують на один ідентичний стан стану, і таким чином вони виглядають однаково.

Отже, в даний час я можу , нарешті , відповісти на ваше запитання.

Чи можете ви скасувати публікацію? Документація ArcGIS скаже вам " ні" - не поспішайте з цим. Не робіть цього, тому що ви будете возитися з цією логікою, і якщо ви не знаєте, що робите, ви можете зіпсувати свої дані.

Але насправді, все, що потрібно, - це зробити одне оновлення однієї з таблиць версій ArcSDE - таблиці VERSIONS та змінити запис мітки (він же названа версія). У нашому прикладі вкажіть на ідентифікатор стану 21, і ви просто скасували всю операцію редагування. Встановіть його на 3, і ви просто відміните все узгодження. Встановіть його на 5, і тепер ви перебуваєте в зовсім іншому місці. Існують чи немає конфліктів - не має значення.

Звичайно, це передбачає, що компресу не відбулося. Розглянемо випадок, коли стиснення відбувається прямо в той самий час, коли ви оновлюєте таблицю SDE. Пам'ятайте, якщо ви - або хтось інший - виконує стиснення після публікації, це виглядає дерево:

Чи можете ви скасувати примирення після компресу? Ну, в цьому випадку - ні . Компрес здув всю цю гілку, тому ви не можете скасувати - ці дані видалено. Якби на цій гілці була інша названа версія, тоді компрес не знищив би її. Я сподіваюся, що до цього часу це має сенс.

То ви повинні це зробити? Якщо ви не знаєте, що ви робите, ви можете легко втратити дані після стиснення.

Існує інструмент під назвою Geodatabase Toolset (GDBT), який є плагіном до ArcCatalog. Він візуалізує стан прокладки та варіанти:

Завантажте GDBT тут

Не знаючи версії та ДБ. ось деяка початкова інформація, яка допоможе вам.
Основний адміністратор
Ось деяка інформація про записування та публікацію
Отже, якщо ви застосовуєте ці поняття та використовуєте команду зміни версії, ви все одно маєте можливість відхилити ці зміни під час запису та публікації за замовчуванням.

У вас немає трьох копій однієї бази даних.
У вас є одна копія з версіями.
Якщо ви керуєте цим db, ви дійсно повинні витратити час (можливо, навіть гроші) і ознайомитеся з усім цим.
Клас esri Універсальне редагування робочих процесів для багатокористувацької Geodatabase є безкоштовним.
Але повним монтом було б те, що я рекомендую людині, яка керує будь-яким різновидом робочого процесу редагування sde.
Цей клас чудовий! для розуміння універсального редагування робочих процесів для багатокористувацької бази даних геоданих .

У мене "швидкий і брудний" спосіб. Переключіть ove на версію за замовчуванням та відредагуйте щось про видалений багатокутник. Тоді, примирившись до типових, ви отримаєте конфлікт. Клацніть правою кнопкою миші конфлікт і скажіть йому використовувати стан попереднього узгодження. Це працює для мене.

Так, ви могли це зробити, але вам доведеться це робити за допомогою SQL.

Я НЕ ЗНАЮТЬ ЦЕ, РОБИТИ ЦЕ ВАШ ВЛАСНИЙ РИЗИК. ВЖЕ ЗАПАСНУЙТЕ свої дані перед тим, як редагувати SDE вручну.

Ви можете запитати таблицю sde.versions, щоб отримати state_id з опублікованої вами версії із змінами, які ви хочете скасувати. Потім ви можете перейти до таблиць A і D і видалити записи, які відповідають стану_id.

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

Тепер у вас є стан інтересу. Тепер вам потрібно знайти таблиці A і D для класу функцій. Ви робите це, запитуючи таблицю_реєстру. Значенням буде register_id. Отже, щоб отримати таблиці A і D, просто додайте register_id до A і D.

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

Потім просто запитуйте та таблицю A і D і видаляйте записи, які містять state_id, з вищезазначеного запиту.

Щоб дізнатися більше про стосунки батьків і дітей, просто запитайте з наступних таблиць sde.

    state_lineages
    versions
    states

Усі вони мають стосунки, і вони повинні допомогти вам слідкувати за підстрибуючим м'ячем.

Неможливо скасувати зміни, коли вони були опубліковані від дочірньої версії до батьківської версії. Дивіться: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

Операцію публікації не можна скасувати, оскільки ви застосовуєте зміни до версії, яку ви зараз не редагуєте.

Ви можете переглянути зміни, внесені в кожній версії під час процесу узгодження - це буде шанс відхилити певні зміни. Процес примирення пояснюється тут .

Так, як казали інші, коротка відповідь - ні.

Версія SDE настільки перспективна, але прикро, що її робочий процес передбачає лише зміну функцій вперед.

Повнофункціональна версія в SDE запропонує інструменти, які:

• Дозволяє (на рівні функції) відкати та приймати / відхиляти
• Дозволяє скасувати
• І дозволить скасувати попередні стани (тобто, починаючи з stat 3, скасувати зміни від стану 1, але зберегти зміни від стану 2).

Це було б як система версій версій управління кодом SVN, але для просторових особливостей.

Проста відповідь - НІ.

Мета розміщення версії полягає в фіксації цих змін в цільової версії.

Відкат здійснюється за допомогою не опублікування версії (і будь-яка практика видаляти будь-які такі занедбані версії).

Під час редагування версії додаток для редагування (наприклад, ArcMap) може забезпечити різні рівні "скасувати", і користувач може вибрати збереження / не зберегти такі зміни до редагуваної версії.

Але після публікації до цілі (наприклад, sde.default) єдиний спосіб скасувати - через хаки до системних таблиць sde.