Вопрос про skipDeleteMethod

[Kozerog]

Привет!

Почему не работает следующий код?

priceDiscTable.skipDeleteMethod(true);
delete_from priceDiscTable
where priceDiscTable.relation == PriceType::LineDiscSales &&
priceDiscTable.AccountCode == TableGroupAll::Table &&
priceDiscTable.AccountRelation == "4";
priceDiscTable.skipDeleteMethod(false);

Отрабатывает delete() на таблице.

[lev]

возможно нужно ещё skipDatabaseLog(true);

[DSPIC]

Из devGuide:
The delete_from statement enables you to delete multiple records from the database at the same time. This means that there is only one call required to the database from the Microsoft Dynamics AX client. as opposed to the multiple calls required if you use the delete statement.

This reduction in the number of calls required speeds up system performance. It also enables you to specify multiple deleted items in a clearer, simpler manner.

In situations where the delete method is overridden, the system transparently emulates the situation of selecting and deleting one record at a time so that the overridden delete method is executed.

Не ленитесь сначала поискать самому ответ на вопрос.

[oip]

Цитата:

What prevents fast SQL operations?
There are a number of situations where X++ recordset operations can fall back to record-by-record operations.
The table below identifies these situations:

DELETE_FROM UPDATE_RECORDSET INSERT_RECORDSET ARRAY_INSERT Use...to override
Non-SQL tables Yes Yes Yes Yes not applicable
Delete actions Yes No No No skipDeleteActions()
Database log enabled Yes Yes Yes No skipDatabaseLog()
Overloaded method Yes Yes Yes Yes skipDataMethods()

Dev Guide

[Hyper]

Цитата:

Сообщение от Kozerog

priceDiscTable.skipDeleteMethod

Надо priceDiscTable.skipDeleteActions

[DSPIC]

2Hyper: не вводите людей в заблуждение, deleteAction и deleteMethod - "немного" разные вещи

[ZVV]

Цитата:

Сообщение от DSPIC

2Hyper: не вводите людей в заблуждение, deleteAction и deleteMethod - "немного" разные вещи

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

Более, того, для множественных вставок ещё существенным является наличие в таблице мемо или контейнерных полей. (это скорее оффтоп).

[petergunn]

2 Kozerog:

Уточните версию Axapta.
В Dynamics Ax 4.0 понижение оператора delete_from возможно еще по следующим причинам:
1. перекрыт метод aosValidateDelete() или aosValidateRead() таблицы (помимо метода delete() ) (вызов метода skipAosValidation(true) предотвращает проверки выполняемые методами aosValidateDelete() и aosValidateRead() )
2. настроена отправка оповещений при удалении записей в таблице ( вызов метода skipEvents(true) предотвращает проверку )

[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() на таблице

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