Могут ли отмененные или отклоненные опубликованные правки при версионировании с ArcSDE?

Я использую ArcGIS 9.3.1 и пытаюсь работать с базой геоданных SDE (с одним классом объектов полигонов), которая уже зарегистрирована как версионная. Я новичок в управлении версиями и все еще пытаюсь выяснить некоторые из его основных функций. До сих пор я не смог выяснить, можно ли «отменить» или «отклонить» определенные изменения после их публикации в родительской версии.

Например, допустим, у нас есть три версии: исходный SDE.DEFAULT, который был создан, когда он был зарегистрирован как версионный, дочерняя версия по умолчанию с именем SDE.QA (для обеспечения качества) и дочерняя версия QA с именем SDE. .Edit1 (где редактирование происходит в первую очередь). Если бы некоторые функции SDE.Edit1 были отредактированы (например, для простоты, скажем, один полигон был добавлен, а другой удален), а затем SDE.Edit1 был согласован с SDE.QA и впоследствии размещен в SDE.QA, Будет ли способ позже отменить это изменение? Следуя этому вопросу, возможно ли отклонить только некоторые изменения? Например, принять добавление первого поли, но отклонить удаление второго поли?

Насколько я могу судить, после публикации изменений в родительской версии все эти изменения теперь являются «постоянной» (из-за отсутствия лучшего слова) частью родительской версии. Я осознаю тот факт, что все эти изменения записаны в двух таблицах, таблицах «ДОБАВИТЬ» и «УДАЛИТЬ» (часто называемых таблицами «дельта»), и фактически не изменяет сам исходный FC. Я подумывал о том, чтобы вручную изменить эти дельта-таблицы, но нашел достаточно людей, которые предупреждали об этом, чтобы понять, что это, вероятно, не правильное решение.

Возможно, мое понимание версионности требует некоторой работы, но я не могу найти способ отклонить изменение или отменить изменение после его публикации. Это кажется странным для меня, поскольку это будет означать, что нет способа отменить сообщение, содержащее ошибку. Я также не могу найти способ отследить происхождение этих версий (то есть, какая версия является потомком какого-либо родителя). Хотя я и занимаюсь этой темой, если кто-то может знать о каких-либо особенно полезных ссылках на ArcSDE (ссылки, статьи, книги и т. Д.), Которые могут помочь мне в понимании ArcSDE (и, возможно, ответить на некоторые из этих вопросов), я был бы весьма признателен !

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

Можете ли вы отменить (под реверсом, я имею в виду, отменить ) сообщение, если оно сделано из дочерней версии в родительскую? В этом сценарии родитель может быть, но не обязательно, версией SDE.DEFAULT. Еще лучше, я хотел бы знать, если вы можете отменить часть сообщения (скажем, одно редактирование на многоугольник), после того, как он был опубликован? Я также хотел бы знать, можно ли это сделать без необходимости обнаружения каких-либо конфликтов.

Тот факт, что я не могу найти четкого ответа на этот вопрос (например, «да» или «нет»), задокументированного где-либо, заставляет меня думать, что я упускаю что-то важное в версионировании в ArcSDE. Я также предпочел бы избегать манипулирования таблицами A и D вручную.

Тьфу. Ответ действительно сложный, требующий большого опыта работы с ArcSDE, поэтому я постараюсь быть максимально кратким.

Обратите внимание, что я собираюсь сослаться на некоторые диаграммы из супер-классного документа по версиям, который вы можете найти на сайте ESRI . Если вы имеете дело с версионированием, я настоятельно рекомендую вам внимательно прочитать его.

Затем вам необходимо понять, какова связь между состоянием (то есть узлом из дерева состояний) и именованной версией (то есть меткой, указывающей на состояние).

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

Здесь у вас есть четыре версии в базе данных (версия A, версия B, версия C и DEFAULT). Но, возможно, я немного опередил себя. Давайте начнем с того, что такое государство .

Вы можете думать о состоянии как о «транзакции» - логической единице, которая содержит несколько правок одной или нескольких таблиц. Он может включать две вставки в «FeatureClass A», удаление из «Feature Class B» и изменение (фактически удаление + вставка) в «Feature Class X». Все сгруппированы в одно.

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

Если вы начинаете с состояния 0 и вносите изменения в одну или несколько таблиц в операции редактирования, вы создадите дочернее состояние 1 и сделаете его текущим идентификатором активного состояния . Другая последующая группа изменений создаст дочернее состояние 2. Если вы хотите отменить, вам не нужно каким-либо образом изменять идентификатор состояния - все, что вам нужно сделать, это изменить текущий идентификатор активного состояния на 1 или 0 (в зависимости от как далеко назад вы хотите пойти). Повторить это наоборот - просто переместить текущий идентификатор текущего состояния вперед - так далеко, как вы хотите.

Вот как работает отмена / повтор в версиях ArcSDE.

ОК, двигаясь дальше. Скажем, что вы хотите сделать редактирование постоянным (т.е. вы хотите сохранить). Что ты должен делать? Что ж, сохранение - это просто захват метки версии и ее перемещение в определенное состояние. Вроде как штамповать его и говорить "вот как должна выглядеть Версия А". Итак, если вы оглянетесь на первую диаграмму, вы увидите, что она имеет четыре названные версии .

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

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

  Обратите внимание, что эта диаграмма, несмотря на распространенное мнение, не говорит вам ничего о логических отношениях между родителями и детьми, которые они имеют. Логические отношения родитель-потомок для первой диаграммы могут выглядеть так:

Это отношение родитель-потомок, которое вы видите в ArcMap / ArcCatalog. Его цель - ограничить, с какими версиями вы можете согласовать. В этот момент вы могли бы (по праву) спросить себя, какого черта мне это нужно? Ответ заключается в рабочих процессах управления версиями . Оказывается, люди используют версионирование уже довольно давно, и есть некоторые предпочтительные способы их структурирования, но это тема другого дня, так как я хочу ответить на ваш вопрос сегодня :)

Двигаясь дальше ...

Хорошо, так что еще делают эти именованные версии? Ну, они влияют на то, как ведет себя этот процесс, называемый сжатием .

Compress - это захват промежуточных состояний, которые могут быть не нужны, и удаление ненужных, а также их объединение. Вы можете запустить операцию сжатия ArcSDE через ArcCatalog, настроить сервис, который делает это каждый раз, и некоторые операции редактирования ArcMap будут запускать операции мини-сжатия (т. Е. Только для небольших используемых веток).

Диаграмма слева показывает дерево состояний до его сжатия, а справа - сразу после сжатия:

Важная концепция, которую нужно понять (на которую я буду ссылаться после того, как я наконец получу ответ на ваш вопрос), состоит в том, что каждое отдельное состояние является потенциальным кандидатом на сжатие, за исключением состояний, на которые указывают метки (то есть именованные версии).

Вы можете видеть, что перед сжатием есть некоторые лишние ненужные состояния. Фактически, вся [3,4,5] ветка была удалена. Если бы была названная версия на 5, конечный результат был бы совсем другим.

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

ОК, двигаясь дальше.

Последняя концепция, которую вам нужно понять, - это согласование, которое фактически объединяет две ветви в одну.

Итак, давайте вернемся к нашей самой первой диаграмме. Скажем, что вы хотите согласовать версию A с SDE.DEFAULT.

Напомним: четыре именованные версии, указывающие на различные идентификаторы состояния. Итак, первое, что нам нужно сделать, это создать дочернее состояние под целевой версией, поэтому мы создаем дочернее состояние под идентификатором состояния 4, в нашем примере я называю этот идентификатор состояния 20.

Следующим шагом является вычисление различий между обеими версиями (детали слишком длинны для этого поста, но я могу сказать, что они сделаны с помощью курсоров различий ), а затем применение этих различий к этому новому идентификатору состояния 20 (синяя линия).

Скажем, вы решили сделать больше правок или обнаружили конфликты и выбираете строки из одной или другой версии. Это не важно Это просто новые правки, которые выполняются внутри операции редактирования, как дочерние состояния под слитой ветвью. В этом примере я сделал еще две последовательные группы правок после согласования.

Прекрасный.

Так что теперь говорите, что вы готовы « опубликовать » версию. Что это значит? Это просто захват меток и указание их на один и тот же идентификатор состояния. Здесь я собираюсь опубликовать версию A в SDE.DEFAULT. Вот как это выглядит:

TADAAA! Так что теперь версии A и SDE.DEFAULT указывают на один и тот же идентификатор состояния, и поэтому они выглядят одинаково.

Хорошо, теперь я могу наконец ответить на ваш вопрос.

Вы можете отменить пост? Документация ArcGIS скажет вам нет - не связывайтесь с этим. Не делайте этого, потому что вы будете возиться с этой логикой, и если вы не знаете, что делаете, вы можете испортить ваши данные.

Но, по правде говоря, все, что нужно, это сделать одно обновление одной из таблиц версий ArcSDE - таблицы VERSIONS и изменить запись метки (называемой версией). В нашем примере укажите на идентификатор состояния 21, и вы только что отменили всю эту операцию редактирования. Установите его на 3, и вы просто отмените все согласование. Установите его на 5, и теперь вы находитесь в совершенно другом месте. Есть ли конфликты или нет, не имеет значения.

Конечно, это предполагает, что компресс не произошел. Давайте рассмотрим случай, когда сжатие происходит именно тогда, когда вы обновляете таблицу SDE. Помните, что если вы - или кто-то еще - выполняете сжатие после того, как вы разместили, то дерево выглядит так:

Можете ли вы отменить примирение после компресса? Ну, в этом случае нет . Сжатие уничтожило всю эту ветку, поэтому вы не можете отменить - эти данные были удалены. Если бы в этой ветви была другая именованная версия, то компресс не уничтожил бы эту ветку. Я надеюсь, что сейчас это имеет смысл.

Так ты должен сделать это? До вас, если вы не знаете, что делаете, вы можете легко потерять данные после сжатия.

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

Скачать GDBT здесь

Если не знать версию и дб. Вот некоторая начальная информация, которая поможет вам.
Базовый администратор
Вот некоторая информация о rec и post.
Поэтому, если вы примените эти концепции и воспользуетесь командой изменения версии, у вас все еще будет возможность отклонить эти изменения при записи и публикации по умолчанию.

У вас нет трех копий одной базы данных.
У вас есть одна копия с версиями.
Если вы управляете этим БД, вы действительно должны потратить время (возможно, даже деньги) и ознакомиться со всем этим.
Класс esri Versioned Editing Workflows для многопользовательской базы геоданных является бесплатным и поможет некоторым.
Но я могу рекомендовать его всем, кто управляет любым версионным рабочим процессом редактирования sde.
Этот класс отлично! для понимания процессов редактирования версий для многопользовательской базы геоданных .

У меня "быстрый и грязный" способ. Переключите ove на версию по умолчанию и отредактируйте что-нибудь об удаленном многоугольнике. Затем, когда вы согласитесь с настройками по умолчанию, вы получите конфликт. Щелкните правой кнопкой мыши конфликт и скажите, чтобы он использовал состояние предварительной согласования. Меня устраивает.

Да, вы можете сделать это, но вам придется делать это с помощью SQL.

Я НЕ СОГЛАШАЮСЯ С ЭТИМ, ДЕЛАЮ ЭТО НА СВОЙ РИСК. ВСЕГДА СОЗДАЙТЕ ВАШИ ДАННЫЕ ПЕРЕД РЕДАКТИРОВАНИЕМ SDE ВРУЧНУЮ.

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

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

Теперь у вас есть state_id интереса. Теперь вам нужно найти таблицы A и D для класса объектов. Вы делаете это, запрашивая table_registry. Значением будет регистрационный_ид. Таким образом, чтобы получить таблицы A и D, просто добавьте регистрационный идентификатор к 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 предлагает инструменты, которые

• Разрешает (на уровне возможностей) откат и принимать / отклонять
• Позволил бы отменить
• И разрешает отмену предыдущих состояний (то есть, начиная со стат 3, отменяет изменения из состояния 1, но сохраняет изменения из состояния 2).

Это будет похоже на систему контроля версий исходного кода SVN, но для пространственных объектов.

Простой ответ - НЕТ.

Целью публикации версии является фиксация этих изменений в целевой версии.

Откат выполняется, если не опубликовать версию (и это хорошая практика, чтобы удалить любые такие заброшенные версии).

При редактировании версии приложение для редактирования (например, ArcMap) может предоставлять различные уровни отмены, и пользователь может выбрать сохранение / не сохранение таких изменений в редактируемой версии.

Но после публикации в цель (например, sde.default) единственный способ отменить это через взлом системных таблиц sde.