Показать сообщение отдельно
Старый 25.01.2018, 22:12   #14  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Skolos Посмотреть сообщение
Может я по не опытности еще не придумал лучший вариант и не полностью разобрал ваши ответы, пока на ум приходит только один вариант реализации без этого аргумента.

Делаем таблицу myTable с двумя полями.
Enum::NoYes поле isSynch
RefRecId поле CustTableRecId

Связываем ее с CustTable. На insert CustTable вешаем создании соответственной строки и в моей новой таблице. на событие onUpdated CustTable вешаем myTable.isSynch = NoYes::No.
А обработчик синхронизации будет lделать. myTable.isSynch = NoYes::Yes

таком образом я избавляюсь от необходимости в аргументе на update.
Да, это тот вариант, который предлагают другие участники. Более того, так в системе уже активно делают и еще в AX 2012, когда таблицы "режут по вертикали" и связывают 1:1 по RecId.
Вариант с myTable - хороший вариант. Более того, дополнительное поле isSynch даже не нужно. Его роль будет играть наличие записи в myTable. Собственно говоря событие update() тут и не нужно. Приходит обработчик синхронизации, забирает записи из CustTable и вставляет забранные RecId в отдельную таблицу. Это событие (с т.з. бизнес-пользователя) никак не связано с изменением какого-либо другого поля типа "Налоговая группа" непосредственно в CustTable.
Отобразить галку в CustTable можно с помощью дисплей-метода, который будет делать exists join к myTable. Фильтровать - также по (not) exists join (тут придется немного покодить, если захочется организовать пользователю фильтр по этому полю, однако задача глобально - решаема).

Так что в контексте этой задачи использовать методы insert / update для вставки своей логики - не нужно. В отношении delete, если реализовать каскадное удаление в myTable, то на delete в myTable можно будет послать какой-нибудь сигнал второй системе. Но это уже не на CustTable, а в myTable - т.о. штатный функционал не трогается.

Цитата:
Сообщение от Skolos Посмотреть сообщение
И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?
Тут есть такое понятие, как модель. Править таблицу можно только в рамках одной модели. При этом не должно быть циклических ссылок моделей друг на друга. Использование же одной большой модели приведет к тому, что каждый билд будет равняться глобальной компиляции всего дополнительного (кастомного) кода. Т.о. не исключен риск того, что Вам придется делать расширения (Extensions) на объекты из другой модели, лишь бы не делать из другой модели ссылку на Вашу модель.

Поэтому на мой взгляд лучше избегать использования insert / update / delete, чтобы впоследствии не пришлось бы управлять последовательностью вызова многочисленной толпы обработчиков insert / update / delete. Ряд задач может решиться с помощью дополнительных узкоспециализированных таблиц.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: ax_mct (3), Skolos (1).