Лучший способ пометить док-ты как обработанные?

Мыш

Премиум
12.02.2008
1 097
10
#1
Всем здрасьте. Вопрос, вроде, обсуждался, но не могу найти поиском.
Есть в некоей отдельной базе background-агент по расписанию, который лазает по разным базам и обрабатывает док-ты в них (для задачи типа лотусовой подписки). При этом доступа на редактирование док-тов и дизайна этих баз может и не быть. Вопрос - как лучше пометить уже обработанные док-ты, чтобы повторно их не учитывать?
Изначально придумался вариант - вести могучий лог с UNID всех док-тов и REPLICAID баз. Но уж больно монстроидально, ИМХО. Плюс проблема с модифицированными док-тами возникает (правда, пока она неактуальна, но...)
Вариант с отбором док-тов, модифицированных с момента последнего запуска агента - честно гря, не шибко доверяю я лотусовому времени...
Щас смотрю в сторону UnreadMarks (GetAllUnreadEntries и т.д.), но вот не знаю, насколько это надежно будет пахать.
Возможно, есть еще какие-то варианты?
 

savl

Lotus team
28.10.2011
2 135
104
#2
@Мыш, хм...

UnreadMarks... у них с репликацией плохо...
Еще можно в обрабатываемый документ писать поле с именем агента и туда дата/время обработки.
Можно к каждому обрабатываемому документу делать ответку об обработке)
Можно файлы на ЖД создавать и проверять наличие.

Но я за базу и ничего "монстроидального" в этом не вижу:
Отдельная база, куда агент создает документ, при обработке.
Документ имеет поля: реплика, UNID обработанного документа, дата обработки, время обработки.
Агент, который обрабатывает:
Находит документ-цель обработки, проверяет в базе по ключу: реплика+UNID+дата.
Находит факт обработки.
Если несколько обработок в день сравнивает даты модификации и дату последней обработки.
Если одна обработка в день - пропускать.
Ошибка была - обработать.
Можно на каждую базу свою базу "логирования" сделать...
Можно вьюху адаптировать, чтобы только за текущий день отображались документы...
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 583
269
#3
Щас смотрю в сторону UnreadMarks (GetAllUnreadEntries и т.д.), но вот не знаю, насколько это надежно будет пахать.
у меня оно доверия не вызывает
можно вести файловый лог (способ разбивки ротации и т.п. - надо подумать) или местную РСУБД поднять (легковесные к-л)
 

Мыш

Премиум
12.02.2008
1 097
10
#4
Еще можно в обрабатываемый документ писать поле с именем агента и туда дата/время обработки.
@savl, к сожалению, по условию задачи модифицировать исходные док-ты нельзя...
UnreadMarks... у них с репликацией плохо...
Точно, забыл про это - спасибо :)
 

rinsk

Lotus team
12.11.2009
900
44
#5
Если сравнивать lastMod и Unread - LastMod гораздо надежнее. И если нужно всю коллекцию обработать то достаточно грохнуть SavedLastMod.
Другое дело, если приклада не озаботилась наличием поля timestamp - тут могут возникнуть проблемы в кластере или на новой реплике.
@lmike
давно руки чешутся прикрутить SQlLite или еще чего ть подобное...
 

garrick

Lotus team
26.10.2009
898
61
#8
Мне кажется на сервере надо использовать то, что общепринято в вашей организации, например Oracle, DB2 & etc., для любых, даже мелких задач, а не разводить "зоопарк" и не создавать лишнюю головную боль вашим администраторам СУБД. Исключения могут составлять только какие-нибудь in-memoty базы, не сохраняющие данные в файлах, ну на худой конец только временные файлы, которые будут удалены по завершению процесса и не требуют администрирования.
 

savl

Lotus team
28.10.2011
2 135
104
#9
@garrick, это конечно хоршо и правильно.
Но, как правило, такими базами занимается другой отдел и не редко этот отдел более загружен работой, либо сильно спланирован.
Следовательно привлечение сотрудника для помощи в решении задачи - большой вопрос.
Могут просто отказать с фразой: "ищите альтернативу".
Простой прагматизм: данное решение уже будет занимать 2 отдела (грубо говоря).
Следовательно, если будет сбой на устранение надо будет привлекать сотрудников второго отдела, что может быть крайне нежелательно.
Вывод: найти альтернативу, если она есть. Если нет - согласиться.
 

rinsk

Lotus team
12.11.2009
900
44
#10
@garrick,
Непонятно почему инмемори и почему оно должно исчезнуть?:) Пусть полежит пару гигов рядом с остальными... Коллега на ветке отписывался о 17кк - я так понял сборщик логов. Явно не доминошная задача в доминошной среде. Напрашивается автономный класс Java\Ls2J с авто установкой на сервере ядра SQlLite\H2 для агрегацией большого кол-ва данных простыми запросами. Пусть живет :)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 583
269
#11
+ @rinsk, при современных объемах - может действительно оказаться "мелочью" +2Гб
@garrick, при установке браузеров (хотя это не серверный вариант ;) ) никто не переживает о SQLite, кот. с ними идет "в нагрузку"
а уж как кэшами и индексами гадят браузеры - врядли кого удивишь
в свете развития идей плагинов, на сервере домины, DOTs (включен в 9.0.1) - как частность, с деплойментом вопросов не возникнет
 

garrick

Lotus team
26.10.2009
898
61
#12
@garrick,
Непонятно почему инмемори и почему оно должно исчезнуть?
Если вы хотите что-то хранить в СУБД, будь то Log или что-то другое, гораздо правильнее если в дальнейшем обслуживанием этого будет заведовать специально обученный амин по этой СУБД (бэкап, восстановление, если вдруг не дай Бог... и пр.). Если вдруг что-то нештатное произойдёт с этой базой, то тоже лучше если у вас есть квалифицированный специалист именно по этой базе. А если у вас везде в организации Oracle, а вы используете H2, то в случае чего вам самим в этом ковыряться и с этим разбираться, т.к. штатные СУБД админы сами знаете что вам скажут. А так, да. Я бы отдал предпочтение pure-Java СУБД, т.к. Derby, H2, HSQLDB - меньше проблем при переезде сервера с одной ОС на дргую ОС.

З.Ы. А почему в новом форуме цифры меньше букв ростом?
[DOUBLEPOST=1424263782,1424263519][/DOUBLEPOST]
@garrick,
Коллега на ветке отписывался о 17кк - я так понял сборщик логов. Явно не доминошная задача в доминошной среде.
Небольшой Log можно вести в обычном файле, смотреть по HTTP, как это и сделано в клиенте (см. Help->Support....)