Цитата:
Сообщение от
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. Ряд задач может решиться с помощью дополнительных узкоспециализированных таблиц.