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

[Ruska132]

Добрый день Извините за беспокойство.
Пользователь удаляет документ через delete потом F9 и документ не отображается в представлении но при выводе отчета от выходит.
Как можно удалить данные документы сразу из базы, при нажатии delete.
Заранее спасибо.

 

[Ruska132]

Добавлю немного
Как на кнопку delete назначит работу агента, а не метить запись к удалению.

 

[savl]

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

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

 

[Ruska132]

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

А как можно изменять значение Поля (флаг) если пользователь нажал сперва delete потом F9.

 

[savl]

Database Script, событие QueryDocumentDelete

@Ruska132,

 

[alexas1]

если пользователь нажал сперва delete потом F9.

Database Script, событие QueryDocumentDelete

- ещё раз - @savl имел ввиду запрет удаления "delete потом F9" и рисование кнопы для "удаления", где и прописать "флаг" для "удаляемых" доков (не забыть отрефрешить текущий workspace)

 

[savl]

@alexas1, или сам скрипт в этом событии, который делает тоже самое.

 

[lmike]

прописать "флаг" для "удаляемых" доков

возможно и просто менять форму на дополненную префиксом (типа $$-<имя формы>) - что автоматом сделает её невидимой во вьюшке (как пр-ло настроенной для отображения нек. форм)

 

[ToxaRat]

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

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

чудовищная и глупая практика!

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

 

[lmike]

2) никаких нагрузок на индексер
3) просто и лаконично

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

 

[savl]

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

Переносить можно ночью, агентом.

 

[ToxaRat]

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

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

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

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

 

[lmike]

потому как в рабочей базе ваш док светится в 10-20 видах

это кто так делает? не нужно проецировать свои подходы на остальных

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

вот уж не факт и зависит от процесса
[DOUBLEPOST=1450868233,1450868050][/DOUBLEPOST]и потом...
если БД активно используется то нагрузка на индексер будет обязательно, а вот какой процент этой нагрузки ляжет на изменение нескольких доков (полагаю - очень малый)

 

[garrick]

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

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

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

А удаление документа из одной базы и "появление" его в другой никак на индексёр не повлияет? По-моему, тоже самое только два раза.

 

[Shandrik]

А удаление документа из одной базы и "появление" его в другой никак на индексёр не повлияет? По-моему, тоже самое только два раза.

В базе-корзинке наверняка у вьюшек выставлено мануальное обновление.
А в базе, где удаляют, он один раз дёрнет индексеры и больше никогда не будет.
И на проверку , видит ли этот документ юзер, больше не будут ресурсы тратиться.

 

[lmike]

В базе-корзинке наверняка у вьюшек выставлено мануальное обновление.
А в базе, где удаляют, он один раз дёрнет индексеры и больше никогда не будет.
И на проверку , видит ли этот документ юзер, больше не будут ресурсы тратиться.

и чем это отличается от модификации поля - только больше кода/гимора/нагрузки

 

[Shandrik]

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

 

[lmike]

видит ли этот документ юзер

и как она осуществляется?

 

[ToxaRat]

и как она осуществляется?

постоянно!
каждый раз когда строится индекс видов - для сервера
каждый раз когда вид предоставляется - пользователю

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

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

 

[lmike]

стр-ра и принципы домины могут оцениваться по статье

Ссылка скрыта от гостей

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

убрав док из базы вы

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

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

обрываете кучу цепочек

ухты - и прям-таки без последствий и траты времени

аналогия это удаление из большой базы большого числа окурков

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