Формирование команд программной модификации запроса.
Обработка предназначена для удобного ориентирования в схеме запроса и формирования команд модификации запроса. Отображает объекты и коллекции, используемые в объектной модели. Полезна и для реальной работы и просто для понимания объектной модели схемы запроса.
Отдельная моя статья о преимуществах модификации запроса через схему запроса «Объектная модель запроса «Схема запроса» — теория и примеры использования«
Также на инфостарте есть Справочная схема «Объектная модель запроса»
Порядок работы с обработкой:
1. Берем исходный текст запроса (копируем из конфигурации или пользуемся конструктором запроса)
2. Генерируем дерево запроса.
3. Находим в дереве нужные нам элементы и определяем пути к ним.
4. Двойным кликом по элементам дерева переносим нужные свойства в окно комманд.
5. Редактируем команды модификации запроса.
6. Выполняем команды, проверям, что получилось в результате.
7. Проверенный набор команд переносим в конфигурацию.
Пример работы:
Исходный запрос:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Контрагенты.Наименование КАК Наименование,
Контрагенты.НаименованиеПолное КАК НаименованиеПолное,
Контрагенты.ЮрФизЛицо КАК ЮрФизЛицо,
Контрагенты.Партнер.Наименование КАК ПартнерНаименование
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
Контрагенты.ПометкаУдаления
И Контрагенты.ЮридическоеФизическоеЛицо = &ЮридическоеФизическоеЛицо
Набор команд модификации:
// Изменяем псевдонимы полей
СхемаЗапроса.ПакетЗапросов[0].Колонки[0].Псевдоним = "НаименованиеНашейОрганизации";
СхемаЗапроса.ПакетЗапросов[0].Колонки[1].Псевдоним = "НаименованиеПартнера";
//Добавляем поле в запрос
СхемаЗапроса.ПакетЗапросов[0].Операторы[0].ВыбираемыеПоля.Добавить("Контрагенты.Партнер.ОсновнойМенеджер");
//Добавляем условие отбора
СхемаЗапроса.ПакетЗапросов[0].Операторы[0].Отбор.Добавить("Контрагенты.Наименование = &НаименованиеКонтрагента")
Итоговый текст запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Контрагенты.Наименование КАК НаименованиеНашейОрганизации,
Контрагенты.НаименованиеПолное КАК НаименованиеПартнера,
Контрагенты.ЮрФизЛицо КАК ЮрФизЛицо,
Контрагенты.Партнер.Наименование КАК ПартнерНаименование,
Контрагенты.Партнер.ОсновнойМенеджер
ИЗ
Справочник.Контрагенты КАК Контрагенты
ГДЕ
Контрагенты.ПометкаУдаления
И Контрагенты.ЮридическоеФизическоеЛицо = &ЮридическоеФизическоеЛицо
И Контрагенты.Наименование = &НаименованиеКонтрагента
UPD. Замечания по итогам обсуждений в комментариях:
1. Объектная модель запроса доступна с 8.3.5. Соответственно, на более ранних версиях работать не будет.
2. При модификации чужого запроса необходимо учитывать, что исходный запрос может измениться. В этом случае могут измениться пути к элементам и команды изменения работать перестанут. Эти моменты необходимо отслеживать при обновлении. Возможно, добавить проверки, что это именно нужный элемент и выдать сообщение, если по указанному пути элемент изменился.
В приложении сама обработка и граф типов схемы запроса.
В архиве схема в jpg, черно-белый вариант в .pdf для печати на А4, а также описание в dot-формате. Можно рассмотреть подробнее и изменить отображение на более удобное, например, через Graphviz.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Привязка по индексам в коллекциях довольно опасна. Автору так не кажется?
Что будет, если поставщик вставит поле в выбранные поля или запрос в пакет? Факт этого сразу заметить будет в некоторых случаях очень непросто, т.к. искажение логики запроса может быть весьма не сразу понятным.
(1) tormozit, Согласна, есть такая проблема.
С большой вероятность ошибка всё-таки отловится, так как изменятся пути к элементам.
Например, например, станет недоступно в съехавшем пакете поле «Контрагенты.Партнер.ОсновнойМенеджер».
Либо следующий работающий с запросом код ругнется на изменение полей а результатах запроса.
Хотя, конечно, может проблема и проскочить незамеченной, нарушив при этом логику работы.
Пока не вижу вариантов решения.
Модель новая. Возможно, с наработкой практики какие-то варианты найдутся.
UPD. Как вариант, можно дописывать проверки, этот ли это реквизит.
Например, «Если имя элемента = <Имя>, то изменить на <ИмяНовое>, иначе выдать сообщение».
Аналогично на количество элементов в коллекции и другие свойства.
Если индексы сместятся, то проверка не пройдет и выдастся сообщение пользователю.
(2) Для некоторых узлов дополнительную идентификацию можно проводить по самому содержимому, но в общем опасность универсально не устранима. Об этой опасности надо предупредить потенциальных пользователей методики.
(3) tormozit, Думаю, изначально объектная модель задумывалась для разработки новых запросов в зависимости от условий.
В этом случае разработчик сразу видит, что делает.
Подумаю еще на тему отслеживания изменений при модификации чужих запросов.
1. Вы бы это лучше в какой из вариантов классической/доработанной «КонсолиЗапросов» встроили, цены б ей не было. А то предложенный вариант, мягко говоря, хорош для понимания (которое у спеца и так есть), но не особо удобен для эксплуатации.
2. (1), (3) Целиком присоединяюсь, неудачно сделано. Надо понадёжнее, сами же на эти грабли встанете (проверено личным опытом).
3. Укажите, пожалуйста, что это легко фурычит и вообще актуально только для 8.3.5, а раньше все эти чудеса можно было лишь эмулировать тяжким трудом.
(5) Yashazz, спасибо за мнение, добавила примечания в статью.
Встраивать куда-либо пока смысла особого не вижу.
Основное применение это просмотр объектной схемы запроса и её модификация. Т.е. предполагается, что разработчик понимает, что хочет получить в итоге от запроса и необходимо лишь выяснить, как выполнить нужное изменение запроса программно.
Консоль запросов обычно у каждого своя, к которой человек привык.
Применения объектной модели именно для создания запросов с нуля смысла тоже не вижу.
Вернее, она и так применяется.
Стандартным конструкторов запросов.
Делать свой конструктор запросов смысла нет.
Смелая идея, плюс.
Только, Евгения, имейте в виду, что Схема запроса на сегодня весьма капризна, а разработчик весьма упрям и концептуальные косяки свои признает только под изрядным давлением. Вот, почитайте мои терки с ним, если есть доступ к форуму:
Также исправьте ссылку на статью в Зазеркалье — сейчас она ведет на эту страницу.
(7) boln, Николай, спасибо.
Идея появилась еще после Вашего вебинара в УЦ3 по новым возможностям работы с запросами.
Наконец добралась до реализации 🙂
Доступ есть, почитала.
Я прекрасно понимаю, что эта модель еще будет меняться в новых релизах. Но, думаю, что общая концепция останется той же. Сама идея работы в объектной модели очень удобна, логична и давно применяется в других языках. Просто в 1С еще опыт использования не наработан. Пока просто разбираюсь для себя.
з.ы. ссылку поправила.
(9) Успехов! 🙂
еще одна прикольная вещь
Очень полезная обработка! Хотелось бы ещё фичу:
1) По тексту запроса строится программный код для создания этого запроса.
2) Расширение п.п.1 — сравнение двух запросов и построение программного кода…
(12) MaxS, По пункту 1 была такая мысль.
На момент статьи еще были некоторые проблемы со схемой запроса.
Не получилось сделать стабильно работающий алгоритм преобразования.
На 8.3.7 попробую реализовать.
По пункту 2, на мой взгляд нереально.
Одинаковые по смыслу и результату запросы могут строиться совершенно по-разному.
Их нельзя однозначно сопоставить и выделить отличия.
Наиболее адекватное сравнение — сравнение текста запроса.
Сравнивать объекты менее информативно.
При открытии обработки получаю
Там находится Описание оповещения и вроде как на первый взгляд именно так оно и должно работать и раньше эта обработка у меня открывалась. Платформа 8.3.7.18.45 Не подскажете куда смотреть?
(14) webester, Возможно, у конфигурации режим совместимости 8.2.
(15)Да действительно. Есть вопрос к вам, как к человеку который более менее смог разобрать эту модель. Как добавить вложенный запрос? Я понимаю, что надо добавлять источник, но на этом все. Дальше какой то темный лес. Со всеми остальными данными понятно указываем текстом регистр или документсправочник и поляпсевдонимы к нему. Не могу понять, что надо делать тут. Обработка должна была помочь, но пока тупик. Может почитать где то можно про это?
НЕ работает.
У меня 8.3.10 и описанные вами шаги в ней не возможны:
3. Находим в дереве нужные нам элементы и определяем пути к ним.
4. Двойным кликом по элементам дерева переносим нужные свойства в окно комманд.
НЕТ в дереве псевдонимов колонок и т.п.
Действительно помогает на практике. Особенно для модификации запросов динамических списков типовых конфигураций. Также помогает для модификации собираемых по частям запросов в типовых конфигурациях, когда менять текст запроса через СтрЗаменить рискованно или сложно, но пользуясь схемой запроса можно перебрать запросы пакета, определить нужные запросы на основе значения поля ТаблицаДляПомещения, после чего добавить в них новые поля или условия. Благодаря удобному визуальному представлению схемы, даже модификация вложенных запросов становится понятной и простой задачей. Спасибо за разработку.
Отлично! В мои инструменты эта обработка точно попадет.. Для изменения конфигураций просто незаменима, особенно с учетом что 1С сделала везде вызовы модулей локализации, в которых можно программно изменять форму при создании на сервере..
Как описать конструкцию
в схеме запроса, а точнее в операторе пакета запроса, что бы не перечислять все поля из источника?