Или как эффективно выгрузить и отобразить результат запроса не в табличном документе, а в табличном поле ? В статье сравниваются два способа выгрузки в "дерево" :
- при помощи запроса с итогами
- используя СКД
На ИС остались еще ветераны, которые полагают , что СКД это всего лишь "оформительский бантик" к запросу... В статье мы покажем как использование "бантика" дает резкий прирост производительности при построении сложных отчетов.
Свободное скачивание.
Для бухгалтера : подробный отчет о просроченных долгах контрагентов по 62 счету.
Для программиста : как одним запросом получить выходную таблицу просроченных долгов ? Развитие темы "Подведем итоги. Нарастающие" http://infostart.ru/public/61295/
Очередной универсальный журнал.
Да еще и с выводом в табличный документ.
Неинтересно.
Хотя для самого автора оформление такой публикации ,возможно , было полезным в части освоения механизмов платформы 1С.
Автор в (3) уже обосновал применение "СхемыЗапроса".
Я бы добавил пример когда без "СхемыЗапроса" никак не обойтись.
Допустим, в текущей конфигурации 1с мы должны обрабатывать произвольные запросы к данным ( в синтаксисе запросов 1с) ,поступающие из других приложений 1с или НЕ 1с, используя http-сервис.
Тогда процедура общего модуля в качестве входных параметров имеет :
- строковую переменную "ТекстЗапроса"
- соответствие "ПараметрыЗапроса".
Внутри этой процедуры мы не можем сразу написать :
Запрос= Новый Запрос;
Запрос.Текст = ТекстЗапроса;
Запрос.Выполнить()
Нам нужно как минимум перед выполнением проверить "ТекстЗапроса" на синтаксис.
Далее , используя объект "СхемаЗапроса" , возможны некоторые проверки и исправления текста запроса.
( ну, например, у меня в конкретном решении удаляются из запроса поля выборки с типами "ДвоичныеДанные" ,"Тип")
Без объекта "СхемаЗапроса" такая функциональность была бы невозможна.
(32) Если говорить по существу , то в целом согласен с приведенными доводами.
(32)
Цитата
Я правильно понимаю что вам придется заморочится с кучей проверок, нежели нарисовать сервис и гонять параметры?
Ноги растут из обычной задачи : в центральном узле ERP в периферийных узлах базы разных поставщиков. Если узел 1с то ставим http-сервис - "читает все". Ну, будет он принимать текст запроса длиной 3-4 тысячи символов. И в чем проблема ?
В этом сервисе проверяется только корректность запроса для текущей базы. Заморочки при проверке небольшие : в запросе только один пакет , запрещены вложенные запросы, в некоторых случаях обязательно наличие периода и проч.
Все проверки простые ( используя объект СхемаЗапроса). В ERP создаются шаблоны запросов к каждой базе 1с.
Таким в данный момент мне видится сценарий решения этой задачи.
(30) В статье позабавило применение "СтрЗаменить(..)" .
Автор и комментаторы явно не в курсе , что все обозначенные вопросы
решает программный объект "СхемаЗапроса", полученный из ТекстЗапроса.
Программным способом без всякого парсинга можно проверить синтаксис ,количество пакетов, ограничить число записей (ПЕРВЫЕ), запретить -удалить вложенные запросы ( к табличным частям объектов)
удалить колонки (поля выборки) запроса, и проч. и проч.
Что касается Odata. Основное его назначение - обмен данными.
Если стоит задача произвольного чтения из базы ( сложные запросы с соединениями ) , то он не применим. Возразите ?.
Во всяком случае в статье
для формирования отчета "ОстаткиИДоступностьТоваров" Odata используется только для получения небольшого списка складов . Почему же протокол Odata не использовался при выводе тела отчета ?
Имея возможность выполнить произвольный запрос ( с понятными ограничениями) , не пришлось бы так выкручиваться , прибегая к созданию макета СКД.
Для меня такой пример как "танцы с бубном".
Впрочем , дело вкуса . Для демонстрации и обучения такой пример вполне подойдет.
(30)
Цитата
-Выполнятор может быть использован против вас. Можно запускать кривые запросы и вы даже не поймете почему тормозит.
Кривые запросы возможны и в Odata. И Вы также "не поймете почему тормозит". Я хочу сказать , что общие соображения беспредметны и могут быть повернуты в любую сторону.
(30)
Цитата
-Вы постоянно гоняете текст запроса\код целиком это все равно что ходить в библиотеку со своими книгами и просить библиотекаря из них что то прочитать
Не понял о чем это ? Мы все чего-то гоняем в разные стороны..
(30)
Цитата
-в случае изменения\обновления конфигурации источника, ваши поделки могут сломаться и тогда чинить их придётся во всех базах получателях.
Предполагается , что обработчик метода http- сервиса , реализованного в расширении , проверяет корректность текста запроса перед запуском на выполнение , выполняет запрос и ничего более . Приведите пример такого изменения конфигурации. Оценим его вероятность и вредоносность для сервиса.
А я люблю, если понимать под словами "Пример мир" предоставление некоторого общего концепта , базовой идеи.
Например , концепт "Выполнятор" , суть которого - выполнение произвольного кода на внешнем ресурсе - совсем не нов , но хорош сам по себе. По-моему , красиво. Уверен , что где-то этот концепт или уже развернут или будет развернут в концепцию безопасного применения произвольного кода .
Читая Вашу статью , я задался вопросом а почему сразу "Выполнятор" ? может начать с задачи поскромнее и безопаснее : "Выполнение произвольного запроса на внешнем ресурсе 1с".
В параметрах http-запроса передается параметр "ТекстЗапроса", в обработчике метода пишем
СхемаЗапроса = Новый СхемаЗапроса();
СхемаЗапроса.УстановитьТекстЗапроса(ТекстЗапроса);
И если нет ошибок выполняем запрос и результат его выполнения
запишем в ЗаписьJSON.
В принципиальном плане вроде все просто-понятно .
Скорее всего кто -то уже реализовал эту идею , но на инфостарте я ничего такого не нашел. Не дадите ссылку ?
(21) При изучении наук примеры полезнее правил. (с) Ньютон.
Если я что-то изучаю с нуля мне не правила нужны ( я их потом изучу самостоятельно) , мне нужен сквозной практический пример ( в данном случае создания простейшего http сервиса).
Автор его дает сжато и быстро . На первом этапе другого и не нужно.
Передача параметров, кодировка и проч . неточности обучающийся выяснит после того как поймет , что это за зверь http -сервис.
