Продвинутый курс. МГ сессия от 03.12.10
Представляем новую сессию.
Сегодня были рассмотрены следующие вопросы.
1. Алгоритм обновления.
В “алгоритме обновления” Вы рекомендовали для обновления рабочей базы использовать “сравнение и объединение конфигураций”. Давайте рассмотрим такой случай: в новой конфигурации поставщика был удален объект, например документ. Соответственно, выполняя обновление на рабочей базе через “сравнить и объединить”, используя созданный нами cf файл, механизм не будет в автоматическом режиме проставлять галочку, с целью удалить объект. То есть он “сравнит и объединит” с приоритетом основной конфигурации. Таким образом, мы должны дважды анализировать изменения в конфигурациях: на этапе обновления копии базы и второй раз, когда выполняем “сравнение и объединение” на рабочей базе. А при загрузке конфигурации из файла, мы бы обезопасили себя и не пришлось выполнять двойную работу.
2. Скрыть невидимые по умолчанию.
Для командного интерфейса конфигурации в уроках главы не объяснено назначение кнопки «Скрыть невидимые по умолчанию» слева от поля «Отбор по ролям». В помощи описано, что при нажатии на эту кнопку «…скрываются команды, для которых не установлена общая видимость, и группы без команд.» По поводу общей видимости понятно – система просто уберет те подсистемы, у которых не установлен флаг «Видимость». А что означает «группы без команд»? Как следует из урока 7 по командному интерфейсу конфигурации, имеется в виду скрытие групп команд, в которых нет ни одной команды. Но разве в панели разделов бывают группы?
3. Механика работы RLS.
Есть у нас объект Поступление товаров. Мы для него сделали ограничение, написав запрос с описанием секции “где”. Вот эта секция цепляется к выборкам по данному документы в целом? или к каждому? Или по другому… После соединения запроса с секцией “где”, запрос нам должен вернуть все документы к которым доступ разрешен? Или же он цепляется в момент запроса к конкретной записи документа и она либо возвращается либо нет.
4. Текст запроса RLS.
Cуществует ли возможность отловить текст RLS после преобразования из шаблона? Не преобразованный в SQL текст запроса в профайлере, а еще 1С-ный. Шаблоны в типовых решениях как правило универсальные со множеством директив препроцессору, а нужно
разобраться с какой-то конкретной ситуацией.
5. Недопустимые конструкции.
Пример взят из конфигурации Управление торговлей 11.0.5.4. (шаблон “ПоЗначениям”). Начнем с начала шаблона.
// Проверка правильности параметра Модификатор.
#Если НЕ (“#Параметр(3)” = “НеОграничиватьДоступКГруппам” ИЛИ “#Параметр(3)” = “”) #Тогда
// Когда параметр задан неверно, вставляется строка, чтобы вызвать ошибку сборки ограничения доступа.
НеверныйМодификатор: #Параметр(3)
#КонецЕсли Т.е. фактически RLS после преобразования шаблона может начаться с этой строки (RLS начинается сразу с шаблона)-
НеверныйМодификатор: <Имя параметра>
Как это работает и для чего используется? Будет выведена ошибка с этим текстом?
6. Использование псевдонимов.
Пример далее по тому же шаблону.
Т ИЗ Т // Т – псевдоним текущей таблицы (выбран коротким, чтобы сократить количество символов в тексте параметра-условия на языке запросов).
Откуда взялась эта “Т”? Ее по тексту до этого не было, а текущая таблица в шаблонах обозначается #ТекущаяТаблица…
7. Использование параметров сеанса.
Насколько оправданно использовать ПараметрСеанса типа фиксированный массив в RLS, если рассматривать его как замена вложенного запроса. Т.е. если в рамках сеанса результат некой выборки не меняется, но она часто используется в RLS – имеет ли смысл выводить выборку в
ПараметрСеанса. И есть ли разумные пределы/ограничения размеров такого массива.
Показалось, или голос простуженный?
Так и есть, уже вхожу в норму :)
По п.7.
В запросах рекомендуется вместо ресурсоемкой операции “В” использовать соединение таблиц. Полностью согласен, НО: как наилучшим образом (кратчайшим и быстровыполняющимся) реализовать соединением таблиц аналог конструкции “НЕ В”?
В и НЕ В можно заменить соединением таблиц: основной таблицы и вложенного запроса.
Для получения результата нужно добавлять дополнительное условие (в условие соединения или предложение ГДЕ): ВложенныйЗапрос.Поле IS NULL, тогда получится аналог НЕ В.
Но как мы знаем вложенный запрос не очень хорошо влияет на производительность.
Поэтому лучше вначале описать его как временную таблицу.
И после этого особой разницы между соединением и (НЕ В…) не должно быть.
По п.6.
Насколько я понял, в конструкции “МояТаблица ИЗ Таблица” строка “… ИЗ Таблица” вообще игнорируется! Посмотрите урок 0.21.17.(4:19). Там в тексте запроса вообще синтаксическая ошибка: “Контрагенты ИЗ Справчоник.Контрагенты” из ничего – запрос работает!
Да, совершенно верно, игнорируется.
Забавное поведение.
Первая и вторая ссылка на один файл ..Adv-2010-12-03-QA-01.avi
Исправлено.