Вопрос про skipDeleteMethod

[S.Kuskov]

Честно говоря я долго "тупил" сегодня, когда писал код с использование skipDeleteMethod (сегодня пятница - позволительно). Никак у меня не получалось запретить вызов метода delete(). Наткнулся на эту тему, а здесь всё тоже очень сумбурно. Попробую объеснить что меня завело в пятничный ступор.

А дело всё в том, что подошёл я к этому методу (skipDeleteMethod) немного не с правльной стороны, так сказать попытался использовать не по назначению. Задачу которую я с его помощью попытался решить можно сформулировать так:

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

Причём для меня в данном случае было не важно, будет ли удаление выполняться при помощи групповой операции или преобразуется по каким-то ещё причинам в построчное удаление. Мне было важно обойти бизнес-логику метода delete. И вот я подумал и решил, что skipDeleteMethod - это то, что мне нужно.

Я ошибался. На самом деле метод skipDeleteMethod можно рассматривать только в контексте групповой операций delete_from. Все мы знаем что delete_from будет целиком выполняться на сервере в том случае если в приложениии нет дополнительных припонов типа табличных медодов, deleteactions, настройки лога и оповещений, возможно ещё чего-то. Также мы знаем, что даже при наличии таких припонов, мы можем при помощи набора методов common.skip...() явно указать системе, что в данном конкретном случае нам на все эти действия плевать - для нас главное производительность, мы хотим что бы обработка прошла одним блоком на сервере. Ключевым моментом сдесь является, что плевать нам именно на ВСЕ припоны. Т.е. если на таблице скажем перекрыт метод delete, а также настроены deleteactions, то отказавшить только от DeleteMethod мы не изменим способ выполнения обработки, из-за наличия deleteАctions обработка будет вынуждена пройти "как обычно" - построчно. И тут, внимание, "как обычно" также означает, что будут выполненн стандартный вызов метода Delete! И это не смотря на как бы указанный запрет skipDeleteMethod(true).

Вывод: запреты common.skip...(true) либо работают все вместе либо не работает не один из них. (проверено для сочитания skipDeleteMethod + skipDeleteActions, обощённый вывод требует дополнительной проверки).

Мораль: нельзя, вызывая skipDeleteMethod(true) перед удалением, гарантированно предотвратить вызов метода delete(). Даже если сейчас обработка пройдёт на сервере и delete() не вызовется, завтра может появиться какой-нибудь DeleteActions и всё изменится. Т.е. skip - в данном случае означает не "ни в коем случае не делай это", а "если хочешь, то можешь это не делать"

[Raven Melancholic]

В книге "Inside Microsoft Dynamics AX 2009" (и в переводной версии этой книги) именно такое поведение и описано.
А фразу:

Цитата:

даже если сейчас обработка пройдёт на сервере и delete() не вызовется, завтра может появиться какой-нибудь DeleteActions и всё изменится

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

[lev]

Цитата:

Сообщение от S.Kuskov

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

для этого можно выполнить метод doDelete() на таблице

про скипы верное замечание, тоже наступал на эти грабли