• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Откат изменений в документе

  • Автор темы Akupaka
  • Дата начала
A

Akupaka

Всем привет! :)

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

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

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

прошу к обсуждению, в общем... :huh:
заранее спасибо
 

Murtas

Green Team
11.04.2006
137
1
BIT
4
Для отката потребуются значения из изменяемых документов, а нотусная коллекция будет лишь ссылаться на эти документы - так что не катит

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

Akupaka

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

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

в общем, дилема :) надо пробовать, смотреть использование памяти, иначе не знаю как доказать, что лучше :)

параллельный вопрос, чем мерять объем занимаемой памяти, lsi_info?
 
K

K-Fire

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

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


PS Кол-во памяти тут будет мизерное использоваться при 100 документах, не стоит даже заморачиваться.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!