Все знают, что такое кэш, и зачем он нужен. Но в 1С разработчик обычно использует кэширование только на уровне конфигурации, а в какой-нибудь обработке скорее ломает голову над запросом - как получить все данные за один заход... Хочется рассказать о том, как можно добиться хороших результатов с стратегией "разделяй и властвуй".
Порой нужно быстро вывести на экран таблицу значений, используя СКД \ получить данные отчета в таблицу значений.. Несмотря на очевидность алгоритма - раньше мне проще было загуглить программный вывод, благо эта инфа есть везде. Но постепенно понял как его можно быстро вспомнить, и лишний раз ничего не искать.
Конечно эта статья не для Гуру :) Но я думаю - что любой неопытный в СКД программист сделает для себя небольшое открытие...
Не так давно попал на ситуацию, когда непонятно из-за какого коммита упал тест. Разработал для себя инструмент для выявления тех тестов, которые упали именно после моих правок.
(34) знаю, еще до того как в платформе сделали возможность изменять локальные переменные для такого использовалась отладочная функция ДУ (https://kb.mista.ru/article.php?id=105) Но можно вот так забивать себе голову продумывая "что-же там обнулить, чтобы процесс прервать". А можно сделать фоновый запуск и нажать "Отмена" в режиме предприятия, и не мучиться лишний раз. И запрос к БД например через изменение переменной не прервешь.
Тут кстати еще момент - если в коде допущен контекст невосстановимой ошибки, то это приведет к выбросу рантайма. При фоновом запуске - к завершению только ФЗ, причем зачастую с записью стека в журнал регистрации.
(131) что-то не так сделали.. Вызова внешней нет, исполняется код временной обработки, которая удаляется - потому "Исходный модуль не найден".
Про "предупреждение безопасности" - всегда отрубал защиту от опасных действий на своем раб. месте через запись 'DisableUnsafeActionProtection=*.*;' в conf.cfg, поэтому не могу с уверенностью сказать - из-за этого проблемы, или нет. Ну, попробуйте отключить, посмотрите что будет.
Вообще - странно что есть предупреждения на клиенте при вызове объекта обработки с сервера.. По-идее было бы исключение, а не предупреждение. Либо это толстый клиент.
Я бы в статье еще дал рекомендацию установить и настроить плагин EDTEditing, для блокировки объектов поставщика и исключений их из проверок.
Кстати, не понял - а трехсторонее сравнение как сделать?
Встречал еще где-то способ, в котором конфа поставщика хранится в сабмодуле. Сейчас имеется опыт применения сабмодулей в EDT - есть линия сборки CI\CD, которая таким образом прикручена к нескольким проектам. Разрабатывать скрипты CI удобно, но вот EDT с ним бывает глючит. Не страшно для CI скриптов, но с т.з. конфы поставщика в отдельной репе - на текущий момент даже думать об этом не стоит.
Это все только выглядит красиво, к сожалению.. На деле куча заморочек, больше для гиков. Сейчас как раз обновляю встроенные БСП, БЭД, БИП - через конфигуратор сильно удобнее.
Добрый день, спасибо за статью. Пару замечаний \ мыслей хотел бы добавить:
1) Не Снегопа*д*, а Снегопа*т*
2) В разделе "Запуск конфигуратора" я бы упомянул StartManager 3) Мультибуфер - попробуйте бесплатный ClipDiary. По сравнению с виндовым это как word vs wordpad...
4) ИР только в ОФ - ничего подобного, весьма удобно ими пользоваться и в управляемом режиме, как расширением. Все есть, все работает - отложенная отладка запросов / схем компоновки, с последующим анализом через разбивку запроса на отдельные подзапросы и т.п. Здесь ложка дегтя в том, что требуется поддержка толстого клиента конфой. Многие на него забивают, поэтому с ИР дружить не выходит. А лучше действовать по стандартам, корректно настраивая / оформляя модули: тогда и код становится более простым, и толстый клиент доступен. Кроме того так попросту интереснее.
5) Запуск с параметром "РежимОтладки" - спорная на самом деле вещь.. Активно использую именно фоновый запуск при разработке, потому что это (внезапно) удобно. Если стартануть долгий \ ресурсоемкий по своей природе алгоритм, то его можно легко и просто скинуть после достижения цели отладочного запуска. А при запуске непосредственном придется прерывать рантайм, т.е. перезапускать базу - такое себе.. Особенно при разработке, когда надо часто перезапускать отладку. Уточню - речь о перезапуске внешних отчетов / обработок. Понятно, что при доработке конфы рантайм все-равно придется прерывать для принятия изменений. Но если действовать по алгоритму разработки встроенных модулей через внешние - хотя бы так, как это описано в текущей статье - то можно все делать в текущем сеансе, без перезапуска ИБ. Главное не забыть потом избавится от отладочного кода) Но это прям тема для отдельного обсуждения.
Без особых проблем анализировал фоновое обновление ключей в "производительном" RLS - с моей т.з. удобнее именно через фон это смотреть. Потому что в том же сеансе если нужно процесс скинул, и без перезапуска базы снова запустил.
Минусы такой отладки есть, но все решаемо:
- мерцание при наличии параллельно работающих ФЗ - если речь о разработке в копии - отключаем все регламенты
- мерцание из-за параллельно работающего глобального обработчика ожидания - бывает что вместо останова в нужном месте останавливается где-то в модуле длительных операций. Бывает не так часто, надо продолжить отладку (F5), и если точка останова уже в задании пройдена - то перезапустить исполнение.
(8) да уж, и зачем себе люди раскладки ставят с вводом этих символов, непонятно, они же "привыкли"..
Могу сказать как человек который работает без приспособ позволяющих вводить спец. символы без переключения - это всегда неудобно.. И привыкнуть к такому нельзя.
Рекомендую от всей души заводить русский контекстный префикс в подобных случаях, и не мучить ни себя, ни того кто потом будет с этим работать.
Вижу по структуре, что поход библиотечный, и уже только это вызывает одобрение. Но мой посыл - раз уж делаете хорошо - делайте до конца.
Всем добра)
(126) все он дает. Обработку на шару надо выложить, которая доступна с сервера.
На клиенте вот отладиться не выйдет, это да. Для такого надо ИР использовать, например. Что-то что заменит целиком объект обработки в момент создания.