Удаление документов

Ruska132

Well-known member
21.01.2015
66
0
#1
Добрый день Извините за беспокойство.
Пользователь удаляет документ через delete потом F9 и документ не отображается в представлении но при выводе отчета от выходит.
Как можно удалить данные документы сразу из базы, при нажатии delete.
Заранее спасибо.
 

Ruska132

Well-known member
21.01.2015
66
0
#2
Добавлю немного
Как на кнопку delete назначит работу агента, а не метить запись к удалению.
 

savl

Lotus team
28.10.2011
2 136
105
#3
@Ruska132, никак, надо править Database Script, событие QueryDocumentDelete или как-то похоже.
Там еще есть событие на отмену удаления.
Но это плохая практика, сегодня удалили, завтра надо восстановить... Лучше их прятать из представления по флагу каком-нибудь.

При выводе отчета показывается stub - окурок после удаления, надо при построении отчета проверять доки на doc.IsDeleted и doc.IsValid
Если он не удален и валидный, то обрабатывать, иначе пропускать.
 

alexas1

Lotus team
10.04.2014
734
149
#6
если пользователь нажал сперва delete потом F9.
Database Script, событие QueryDocumentDelete
- ещё раз - @savl имел ввиду запрет удаления "delete потом F9" и рисование кнопы для "удаления", где и прописать "флаг" для "удаляемых" доков (не забыть отрефрешить текущий workspace)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#8
прописать "флаг" для "удаляемых" доков
возможно и просто менять форму на дополненную префиксом (типа $$-<имя формы>) - что автоматом сделает её невидимой во вьюшке (как пр-ло настроенной для отображения нек. форм)
 
Симпатии: Понравилось alexas1

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 233
18
#9
@Ruska132, никак, надо править Database Script, событие QueryDocumentDelete или как-то похоже.
Там еще есть событие на отмену удаления.
Но это плохая практика, сегодня удалили, завтра надо восстановить... Лучше их прятать из представления по флагу каком-нибудь.

При выводе отчета показывается stub - окурок после удаления, надо при построении отчета проверять доки на doc.IsDeleted и doc.IsValid
Если он не удален и валидный, то обрабатывать, иначе пропускать.
чудовищная и глупая практика!

вешаем скрипт на "дел" и ПЕРЕНОСИМ документы в другую базу - научитесь не срать всё в одной базе:
1) никаких доп. флагов
2) никаких нагрузок на индексер
3) просто и лаконично
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#10
2) никаких нагрузок на индексер
3) просто и лаконично
что-то мне подсказывает, что это - не так ;)
создание и копирование доков - нагрузка бОльшая чем изменение поля (а доки могут быть немаленькие)
и уж точно не проще с отслеживанием респонсов
 
Симпатии: Понравилось savl

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 233
18
#12
что-то мне подсказывает, что это - не так
создание и копирование доков - нагрузка бОльшая чем изменение поля (а доки могут быть немаленькие)
и уж точно не проще с отслеживанием респонсов
ну да, заменить одно поле ведь легче для программиста чем всё продумать? ;)
нагрузка меньше потому как в рабочей базе ваш док светится в 10-20 видах и его изменение - не важно какое заставит этот док и в видах переиндексироваться и полнотекстовый поиск для всех видов перестроить - поверьте нагрузка офигенна!

Особенно если у вас там 10К доков и больше

Совсем другое дело отдельная БД Корзинко - где и видов 1-3 и доков меньше 1К
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#13
потому как в рабочей базе ваш док светится в 10-20 видах
это кто так делает? не нужно проецировать свои подходы на остальных ;)
Совсем другое дело отдельная БД Корзинко - где и видов 1-3 и доков меньше 1К
вот уж не факт и зависит от процесса
[DOUBLEPOST=1450868233,1450868050][/DOUBLEPOST]и потом...
если БД активно используется то нагрузка на индексер будет обязательно, а вот какой процент этой нагрузки ляжет на изменение нескольких доков (полагаю - очень малый)
 

garrick

Lotus team
26.10.2009
911
61
#14
ну да, заменить одно поле ведь легче для программиста чем всё продумать? ;)
нагрузка меньше потому как в рабочей базе ваш док светится в 10-20 видах и его изменение - не важно какое заставит этот док и в видах переиндексироваться и полнотекстовый поиск для всех видов перестроить - поверьте нагрузка офигенна!

Особенно если у вас там 10К доков и больше

Совсем другое дело отдельная БД Корзинко - где и видов 1-3 и доков меньше 1К
А удаление документа из одной базы и "появление" его в другой никак на индексёр не повлияет? По-моему, тоже самое только два раза.
 
Симпатии: Понравилось alexas1

Shandrik

Lotus team
30.12.2010
269
12
#15
А удаление документа из одной базы и "появление" его в другой никак на индексёр не повлияет? По-моему, тоже самое только два раза.
В базе-корзинке наверняка у вьюшек выставлено мануальное обновление.
А в базе, где удаляют, он один раз дёрнет индексеры и больше никогда не будет.
И на проверку , видит ли этот документ юзер, больше не будут ресурсы тратиться.
 
Последнее редактирование модератором:

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#16
В базе-корзинке наверняка у вьюшек выставлено мануальное обновление.
А в базе, где удаляют, он один раз дёрнет индексеры и больше никогда не будет.
И на проверку , видит ли этот документ юзер, больше не будут ресурсы тратиться.
и чем это отличается от модификации поля - только больше кода/гимора/нагрузки ;)
 

Shandrik

Lotus team
30.12.2010
269
12
#17
Как минимум :
И на проверку , видит ли этот документ юзер, больше не будут ресурсы тратиться.
 

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 233
18
#19
и как она осуществляется? ;)
постоянно!
каждый раз когда строится индекс видов - для сервера
каждый раз когда вид предоставляется - пользователю

убрав док из базы вы обрываете кучу цепочек связанных с: DB.ALLDocuments - индексы видов, ФТ, коллекции

пример привести сложно, ближайшая аналогия это удаление из большой базы большого числа окурков - и всё сразу быстрее за работало, сталкивались с таким?
тут тоже самое ;)
 

lmike

нет, пердело совершенство
Lotus team
27.08.2008
6 599
277
#20
стр-ра и принципы домины могут оцениваться по статье
Для просмотра контента необходимо: Войти или зарегистрироваться

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

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

ухты - и прям-таки без последствий и траты времени :)
аналогия это удаление из большой базы большого числа окурков
ну т.е. мы таки получили признание - удаление процесс не простой ;), там еще будут и окурки, кот. "мешают"
[DOUBLEPOST=1451908163,1451907956][/DOUBLEPOST]@Ruska132, если нужны "сложные" отчеты..., проще - все "нужное" выгружать в РСУБД (агентом по расписанию) и оттуда получать отчеты