Опердень и undo

[metaclass]

А вот скажите мне, как истинные оперденьщики, модно ли сейчас делать в оперденях функцию "откатить изменения в паре сотен документов на неделю назад, потому что пользователи сошли с ума и сделали что-то не то"?

Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопие за которое положено быть запсенным кахесом и давно все делают иммутабельные БД со всеми версиями происходящего и дичайшими алгоритмами отката части графа документов на предыдущую версию?

Comments

[falcrum.livejournal.com]

А документы не уходят в сторонние системы за неделю-то? Как откатывать?

[vp.livejournal.com]

откатить изменения все или откатить изменения какие-то определенные? если все, то это таки да, резервная копия.

[avnik.livejournal.com]

git же.
Вам и иммутабельность, и версионность и пауки.

PS appendonly еще очень можно и инстаграмно.

[denisioru.livejournal.com]

В опердени не бывает откатов. Документ, попавший в систему остается в ней навсегда. Коррекция выполнется новыми документами (как сторнирование в бухгалтерии).

[vit-r.livejournal.com]

Undo работает только в форме, которая не зарегистрирована. Всё, что попало в двойную бухгалтерию может исправляться только корректирующими проводками.

[berezovsky.livejournal.com]

ещё должна быть кнопка, чтоб пространство и время сворачивались и разворачивались из нужного места, ну, чтоб наверняка

[x-a-e-p.livejournal.com]

Ну если потребность возникает нечасто, то делать версионность смысла нету. Достаточно бекапов.

[chumpa.livejournal.com]

такое популярно и требуется. Если готовая система (SAP, 1c) это не умеет, её ломают/"энханцируют" на предмет. Ибо нефиг.

[rssh.livejournal.com]

после закрытия периода -- только сторнирование

было какое-то время когда возможность пересчета при изменении исходных данных была одим из сертификациооных требований телекоммуникационных биллингов (ну
это отдалеьная область там своий законы) но сейчас законодательство гармонизировано с ISO и странности типа регенерацию счета без сторнирования - убрали.

[mudasobwa.livejournal.com]

У меня была похожая задача. Я в соседней базе хранил «дельты» (ну, не дельты, а предыдущие версии, повторять систему контроля версий как-то странно) с датами (типа: doc_id, date_of_change, old_version). С индексом по дате.

Есть два варианта отката: иногда нужно, чтобы документ откатился назад, но стал «новой версией» (откат на две недели от версии 20 к версии 3 создает не версию 3, но версию 21 с содержимым 3), а иногда можно просто «вернуться к бэкапу».

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

[molnij.livejournal.com]

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

[ng67.livejournal.com]

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

В 1С есть кстати версионирование объектов, то есть можно узнать какая сволочь поменяла дебет с кредитом.

[Дмитрий Васильев (from livejournal.com)]

http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm
http://www.postgresql.org/docs/8.3/static/contrib-spi.html#AEN107671

[dennab.livejournal.com]

Lotus Domino?
FileNet?
IBM Content Manager?