Откат

Гость

Здравствуйте господа-товарищи

Вот, не думал что понадобится когда-либо, а понадобилось...

Понадобилось иметь ПОЛНОЦЕННЫЙ откат.
И прежде чем изобретать велосипед, хотелось бы рассмотреть варианты.
Если кто-то что-то делал подобное - поделитесь опытом, пожалуйста.

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

Желательно иметь неограниченное число шагов назад-вперед или в пределах разумного (несколько сотен шагов).

Сергей - chusha@mail333.com ; chusha@hotbox.ru

(Добавление)

Привет!

Ты случайно не об Undo/Redo?
Если о нем, то уточни в каком контексте?
Хотя, принципиальной разницы нет, все-равно нужно заводить буфер и хранить текущую позицию...
При помещении нового элемента в этот буфер все последующие после текущего предварительно убиваются.
В общем, логика там простая. Я,например, делал такую штуку в самописном графическом редакторе xml форм на Java. Причем у меня там были разнотиповые объекты, хранились как изменения одного свойства контрола (группы контролов), так и изменения в количественном составе контролов и их иерархии. Все стреляет на ура.
Я хочу сказать, что основная и, в общем, единственная трудность - придумать формат хранения элементов в буфере отката.

Успехов!
Сергей.

Желательно иметь неограниченное число шагов назад-вперед или в пределах
разумного (несколько сотен шагов).

Это-то как раз не сложно. Вспомни, как устроены транзакции на DAT-файлах. С помощью BLOB-ов весь протокол (RECORD-ы) можно в один файл залить.
Видишь ли, при наличии мультидоступа и сложной структуры связей между таблицами это не такая самоочевидная вещь, как откат-накат в ворде.
Вот, например, только некоторые вопросы.
Откатывая запись/документ, следует ли откатывать запись/документ, созданную/отредактированную/удаленную соседом?
А если подумать?
То-же самое относительно наката.
Думаю, что самое простое и логически безупречное - это откат/накат на контрольную точку.

WBR, Nick Tsigouro. MailTo:Nick@arsis.ru

(Добавление)

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

Чушкин Сергей

Желательно иметь неограниченное число шагов назад-вперед или в пределах разумного (несколько сотен шагов).

Согласен полностью. Хочу добавить лишь одно. С пользователями были постоянные заморчки, то одно потерялось, то другое не нашлось, но когда я сделал ряд контрольных точек по действию, условию, времени и пр. и предоставил право отката непосредственно пользователю все устаканилось.

Сергей
Написал: ClaList(2)

Гость

Привет, Сергей!

Не совсем понял, что ты хочешь, т.к. приведенные этапы собственно разные задачи.
Откат поля реализован в стандартных шаблонах через специальный статический буфер.
Откат изменений таблицы (таблиц) документа я реализовывал через очередь. В специальном шаблоне указывается список таблиц документа (точнее, их ключ с первым полем=ID заглавной записи). Остальное делается автоматически (запоминаем строки при входе, при отказе проверяем на изменения и изменения восстанавливаем на диск). Но у меня используется логический захват документа, т.е. несколько пользователей одновременно его корректировать не могут.
Откат транзакций несколько месяцев назад активно обсуждался в рассылке (глянь тему Log). Были выдвинуты две схемы - хранение физических изменений и хранение логических операций. В первом случае можно делать откат от текущего момента назад, но объем хранимой информации возрастает и усложняется реализация. Во втором случае возможен только "докат" (от резервной копии до актуального состояния), но реализовать проще. Лично я остановился на втором варианте. Физически все хранится в tps-таблице с указанием имени таблицы, ID записи и кода операции. В memo-поле хранится список измененных полей (для операций Insert и Put), разделенных специальными разделителями, в формате имя поля, новое значение поля. Реализуется через набор шаблонов и несколько процедур (просмотр лога, информация по структуре таблиц, запись в лог, восстановление из лога). Стандартные формы накрываются одним глобальным Extension-шаблоном.
Если нужен именно откат, а не докат, то это может быть Олег Руденко расскажет. Он использует первую схему.
Авторитеты рекомендовали еще использовать колобок

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)

Гость

Если решать каждую задачу отдельно (или последовательно 1-2-3), то получится три совершенно разных алгоритма.
1 - решается элементарно простенькой очередью - имеем ЛЮБОЕ кол-во откатов-накатов
2 - решается так-же очередью с динамическим размером записи.
Правда, по сравнению с п.1, алгоритм более сложен.
Но как и в п.1 - ЛЮБОЕ кол-во откатов-накатов.
У меня, например, таким образом реализован откат для документов с детками.
3 - можно, опять-же, решить с помощью очереди.

Как не трудно заметить, у всех алгоритмов один недостаток -откат/накат возможен ТОЛЬКО в процессе жизни экземпляра программы.

Поэтому приходим к одному, единственно-возможному, варианту - хранить ВСЕ изменения в журнале событий.
Именно ИЗМЕНЕНИЯ, а не ЛОГИКУ, которая допускает ТОЛЬКО накат от ранее сохраненной контрольной точки (снимка) БД.
Т.е. для решения задачи по ТВОИМ требованиям подходит ТОЛЬКО вариант с ведением журнала изменений БД.

Опять-же - два варианта:
- простой журнал изменений отдельных записей каждой таблицы БД
- связанный журнал, в котором записи могут иметь связь с другими записями.

В первом варианте очень трудно обеспечить логическую целостность при откате/накате, если есть хотя-бы одна связка отец-детка.
Поэтому - выбираем второй вариант.

Почему я не рассматриваю вопрос "Нужно-ли делать откат зависимых записей, если они были позже изменены другими пользователями"?
Я исхожу из того, что ВСЕ зависимые записи были порождены в результате создания родительского документа или его изменения.
Поэтому, что-бы соблюсти абсолютную логическую целостность, следует принять правило, что зависимые документы сами по себе или их изменения НЕ МОГУТ существовать, если произошел откат источника их создания/модификации.
Поэтому, если такая ситуация возможна и/или имела место, то она должна решаться просто административно - "Разрешено/Не_разрешено".

Таким образом, получаем схему журнала, при которой возможен как откат/накат отдельного документа, так и откат/накат последовательно всей БД.
Правда, используя откат/накат отдельных документов, следует иметь в виду, что при этом НЕДОСТАТОЧНО привести связанные записи в состояние на начало модификации родительского документа. Следует помнить, что связанные (детские) записи, в свою очередь, могут иметь связь с другими документами, которые не имеют прямой связи с родительским документом.
Поэтому в простейшем приближении алгоритм отката напоминает движение от корня ветки до кончиков ВСЕХ ее отростков.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)

Гость

Здравствуйте

Спасибо всем, - буду думать...

Сергей - chusha@mail333.com ; chusha@hotbox.ru
Написал: ClaList(2)