Коллеги, доброго времени суток!
Есть необходимость вывести дополнительную информацию в виде колонки реестра раздела для каждой записи.
Кейс:
в реестре раздела Контрагенты вывести дополнительную колонку с названием "Контакты", и для каждой записи выводить имена всех Контактов соответствующего Контрагента (из детали "Контакты контрагента").
Необходимо, чтобы контакты отображались даже когда строка неактивна, то есть также, как данные других колонок (всегда).
Обычным способом такую колонку добавить не получается.
Если есть варианты, как реализовать этот кейс другим путем, буду рад их рассмотреть.
Заранее спасибо за помощь!
Нравится
Дмитрий, причина отсутствия колонок в изначальном вопросе в том, что в раздел можно выводить с детали только обобщённые значения: количество, сумму, среднее, минимум, максимум.
Дмитрий Анисько пишет:
то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.
Лучше всего именно так. На уровне встроенного БП объекта детали или отдельным БП заполнять новое текстовое поле в объекте раздела. Можно ещё триггером в базе, но это Вам не подойдёт.
Дмитрий Анисько пишет:
Может быть Вы знаете, как можно добавить колонку в реестр именно на этапе формирования вью-модели?
Даже если такое возможно, рисков больше, чем преимуществ. От большей нагрузки на сервер и базу, когда для каждой видимой в реестре строки будет отдельный запрос, до неполной функциональности, когда такая колонка не будет полноценно работать в выгрузке в Excel, итогах, печатных формах, OData и прочих интеграциях.
Здравствуйте!
Базовыми средствами, не прибегая к разработке, Вы не сможете реализовать подобный функционал.
Вариантов решения такой задачи несколько, например:
1. Добавляем view с 2 колонками - Guid и string. Средствами sql формируем запрос, который в первую колонку будет возвращать Id контрагента, во вторую все "склеенные" в одну строку имена относящихся к нему контактов
2. В контрагенте добавляем колонку-справочник на нашу view (не забываем про галочку контроля целосности)
3. На событии OnInserting контрагента копируем значение колонки Id в колонку из п.2
4. Дальше пользуемся базовой настройкой колонок
Манипуляции из пп. 2-3 нужны для того, чтобы сохранить прямую связь
Лопатин Константин,
Большое спасибо за ответ, но указанный способ не подходит.
Нужно сохранить поддержку всех 3-х субд, а создавать View для каждой - не очень удобно. Да и если идти подобным путем, то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.
Может быть Вы знаете, как можно добавить колонку в реестр именно на этапе формирования вью-модели? Может вы знаете, что можно попробовать переопределить, чтобы изменить стандартное поведение?
Дмитрий, причина отсутствия колонок в изначальном вопросе в том, что в раздел можно выводить с детали только обобщённые значения: количество, сумму, среднее, минимум, максимум.
Дмитрий Анисько пишет:
то на мой взгляд проще добавить строковое поле в объект Контрагент и обновлять его на все нужные события для поддержания актуальности данных.
Лучше всего именно так. На уровне встроенного БП объекта детали или отдельным БП заполнять новое текстовое поле в объекте раздела. Можно ещё триггером в базе, но это Вам не подойдёт.
Дмитрий Анисько пишет:
Может быть Вы знаете, как можно добавить колонку в реестр именно на этапе формирования вью-модели?
Даже если такое возможно, рисков больше, чем преимуществ. От большей нагрузки на сервер и базу, когда для каждой видимой в реестре строки будет отдельный запрос, до неполной функциональности, когда такая колонка не будет полноценно работать в выгрузке в Excel, итогах, печатных формах, OData и прочих интеграциях.
Коллеги, большое спасибо за ответы.
Принимая во внимание лишнюю нагрузку на бд, есть смысл остановиться на варианте со строковым полем.
Дмитрий Анисько пишет:
Коллеги, большое спасибо за ответы.
Принимая во внимание лишнюю нагрузку на бд, есть смысл остановиться на варианте со строковым полем.
Дело, конечно же, Ваше, но я, если честно, так и не понял каким образом уменьшится нагрузка на БД если сравнивать view и обновление колонки после каждого чиха на событийном слое
Нужно сохранить поддержку всех 3-х субд, а создавать View для каждой - не очень удобно
Тоже не вижу особой проблемы с учетом того, что синтаксис аналогичный.
Лопатин Константин пишет:
Дело, конечно же, Ваше, но я, если честно, так и не понял каким образом уменьшится нагрузка на БД если сравнивать view и обновление колонки после каждого чиха на событийном слое
Честно, не тестировал три обсуждаемых варианта, но можно предположить, что данные меняют намного реже, чем читают, следовательно затраты на обновление меньше, чем каждый раз вычислять. Хотя, возможно, с view всё не так страшно, ведь запрос отрабатывает не сервере БД раз и целиком через веб-сервер попадает в браузер. В случае же программной вычитки для каждой записи каждый раз будут отрабатывать и БД, и сервер приложений.