1с отключить проверку корректности метаданных
Особенности использования проверки конфигурации
Механизм проверки конфигурации позволяет выявить ошибки, которые не являются критичными для функционирования прикладного решения в принципе, но наличие которых может существенно снизить скорость работы прикладного решения или даже привести к возникновению ошибок при работе в некоторых специальных режимах.
Выполнение данных проверок не является обязательным (как, например, в случае синтаксического контроля), но является желательным, например, для проверки конфигурации перед поставкой заказчику, перед выпуском тиражного решения, для проверки после массированного удаления объектов или после объединения конфигураций.
Механизм проверки конфигурации включает в себя несколько тестов. Часть этих тестов доступна и в других режимах конфигуратора, а остальные специально разработаны для этого механизма.
Рассмотрим особенности этих тестов:
Проверка логической целостности конфигурации
Проверка логической целостности конфигурации включает в себя ряд стандартных проверок целостности прикладных объектов, которые обычно выполняются автоматически перед обновлением конфигурации базы данных.
Например проверка того, что все объекты метаданных в пределах одной ветки имеют уникальные имена.
Поиск некорректных ссылок
Конфигурация на платформе 1С:Предприятие 8.1 представляет собой набор взаимосвязанных объектов. Каждый объект определяется его свойствами. Эти свойства могут содержать ссылки на другие объекты метаданных.
Ссылки бывают прямые (например, свойство справочника ОсновнаяФорма ссылается на объект метаданных Форма ) или косвенные. К косвенным относятся, например, ссылки на типы, относящиеся к объекту метаданных, например СправочникСсылка.Номенклатура или ссылки на предопределенные значения объекта.
Свойства объектов метаданных можно разделить на простые и сложные. К простым, например, относятся Имя , Синоним , Тип , ОсновнаяФорма и другие. Сложными свойствами являются Форма , Макет , Интерфейс , Права , СправочнаяИнформация .
Логика работы платформы 1С:Предприятие 8.1 построена таким образом, что наличие некорректных (неразрешимых) ссылок в простых свойствах в режиме 1С:Предприятие не допускается. При стандартных операциях редактирования, конфигуратор не позволит возникнуть таким ссылкам.
Например, нельзя удалить форму, если ссылка на нее содержится в свойстве справочника.
Впрочем, получить конфигурацию, которая такие ссылки содержит все же возможно. Например, при объединении конфигурации, если пометить к объединению только один объект метаданных и не помечать объекты, на которые он ссылается. При этом будет выдано предупреждение, но его можно игнорировать и выполнить объединение. Подобное поведение реализовано для облегчения процесса объединения конфигураций. Предполагается, что после объединения разработчик вручную поправит неразрешимые ссылки. Обязательная проверка простых свойств на корректность выполняется при обновлении конфигурации.
Сложные свойства ведут себя несколько иначе. Отслеживание всех ссылок во всех формах представляет собой слишком ресурсоемкий процесс, поэтому наличие неразрешимых ссылок в них допустимо. Допустимо в том смысле, что программа будет работать, однако ее функциональность может быть нарушена.
Например, в форме окажется поле ввода не связанное с данными или в справочной информации будет "переход в никуда".
Для поиска и исправления таких ситуаций предназначен механизм поиска некорректных ссылок. Он позволяет определить только факт наличия неразрешимых ссылок в той или иной форме. Их поиск и исправление возлагается на разработчика.
Ниже приведены некоторые рекомендации, которые могут помочь в данном процессе.
Неразрешимые ссылки в справочной информации
Если неразрешимые ссылки обнаружены в модуле справки, то для их локализации и исправления следует проверить работоспособность всех ссылок, находящихся в указанном модуле.
Если ссылка не работает, но существует объект, на который она ссылается - нужно скорректировать ссылку. Если объект, на который указывает ссылка, отсутствует - нужно, как минимум, очистить ссылку и, возможно, удалить соответствующий текст справки.
Некорректные ссылки в формах объектов
Если неразрешимые ссылки обнаружены в форме объекта, то для их локализации прежде всего следует проверить на непустое значение свойства формы и свойства элементов формы (например такие свойства, как Цвет , Шрифт , Рамка и т.д.). Для табличного поля следует также проверить свойства колонок и элементов управления, расположенных в колонках.
Для всех этих свойств значение в палитре свойств не должно быть пустым, т.е. должно отображаться либо какое-то конкретное значение, либо значение Авто . Все остальные случаи определяются как неразрешимые ссылки.
Для исправления такой ссылки следует либо задать для свойства необходимое значение, либо очистить значение (что приведет к установке значения Авто ).
Также довольно распространенным случаем некорректных ссылок может быть неправильный перечень реквизитов объекта в свойстве формы Сохраняемые значения . Для исправления таких ссылок необходимо открыть окно настройки этого свойства, и ничего не меняя нажать ОK .
Также следует проверять связи с данными. Например, для свойств Связь по владельцу и Связь по типу нужно убедиться, что в окне формы настройки связи будет выбрано конкретное значение. Если нет - нужно заново выбрать нужное значение.
Неразрешимые ссылки также могут возникать в предопределенных элементах. Для исправления таких ссылок может оказаться достаточным установки признака модифицированности списка предопределенных элементов, и последующего сохранения объекта метаданных.
Для автоматизации поиска неразрешимых ссылок можно использовать Проверку конфигурации (команда Конфигурация - Проверка конфигурации в Конфигураторе).
Общие рекомендации
Самый лучший способ борьбы с неразрешимыми ссылками - по возможности не допускать их появления.
Например, как было указано, при удалении объекта конфигуратор проверит наличие ссылок на удаляемый объект, но только в простых свойствах. Поэтому перед удалением рекомендуется провести полный поиск. Обратите внимание, что начиная с релиза 8.1.10, при выполнении команды "Поиск ссылок на объект" (и "Поиск ссылок в объекте") можно указать поиск во всех свойствах.
Синтаксический контроль модулей
Механизм проверки конфигурации предоставляет расширенные возможности синтаксического контроля модулей. Они позволяют проверить работоспособность конфигурации во всех режимах, предусмотренных разработчиком. Для того, чтобы понять назначение каждого из режимов, рассмотрим подробнее особенности исполнения модулей в платформе 1С:Предприятие 8.1.
Конфигурация может исполняться в двух сеансах - клиентского приложения и внешнего соединения. Кроме этого, конфигурация может быть развернута в файловом варианте и клиент-серверном варианте. Различия режимов определяются составом объектов и их свойств. Не все объекты доступны при исполнении на сервере 1С:Предприятия и в режиме внешнего соединения.
Все модули, с точки зрения режимов исполнения, можно разделить на 5 групп. Это общие модули, модуль приложения, модуль внешнего соединения, модули хранимых объектов (обобщенное название, сюда относятся модули объектов, наборов записей) и модули форм.
Общие модули могут выполняться на клиенте, на сервере и в режиме внешнего соединения. Доступность конкретного общего модуля в каждой из этих сред определятся соответствующим свойством.
Модуль приложения всегда исполняется на клиенте.
Модуль внешнего соединения всегда исполняется в режиме внешнего соединения.
Модули хранимых объектов могут исполняться везде. Это зависит того, где был создан соответствующий объект.
Модули форм всегда исполняются только на клиенте.
Важной особенностью 1С:Предприятия 8.1 являются различия между файловым вариантом работы и клиент-серверным. В файловом варинате для всех исполняемых модулей доступен контекст как сервера так и клиента или внешнего соединения, в зависимости от типа сеанса. То есть, даже если у общего модуля в свойствах указано исполнение только на сервере, в файловом варианте работы в нем можно создавать объекты, доступные только на клиенте. Однако при развертывании данной конфигурации в режиме клиент-сервер, выполнение подобного модуля приведет к ошибке.
Для выявления подобных "тонких" случаев, механизм проверки конфигурации предоставляет проверки модулей во всех пяти вариантах среды исполнения.
Работа клиентского приложения
Синтаксический контроль модулей в режиме эмуляции сеанса клиентского приложения в файловом варианте работы.
Работа внешнего соединения
Синтаксический контроль модулей в режиме эмуляции сеанса внешнего соединения в файовом варианте работы.
Среди наиболее часто встречающихся ошибок при тестировании работы в режиме внешнего соединения, можно выделить следующие:
Вызов метода глобального контекста, который не может быть использован в режиме внешнего соединения (например, ВвестиЗначение() ); Использование свойства глобального контекста, которое не может быть использовано в режиме внешнего соединения (например, РабочаяДата ); Создание объекта, который не может быть использован в режиме внешнего соединения (например, Цвет );Вызов процедур общего модуля, для которого не установлено свойство использования во внешнем соединении. Использование переменных, определенных в модуле приложения;Для исправления подобных ошибок следует использовать разрешенные методы, свойства и объекты.
Для исправления подобных ошибок в модуле внешнего соединения необходимо продублировать экспортные переменные, а также, при необходимости, процедуры их заполняющие.
Работа клиентского приложения в режиме клиент-сервер
Синтаксический контроль модулей в режиме эмуляции сеанса клиентского приложения в клиент-серверном варианте.
Работа внешнего соединения в режиме клиент-сервер
Синтаксический контроль модулей в режиме эмуляции сеанса внешнего соединения в клиент-серверном варианте.
Работа сервера 1С:Предприятия
Синтаксический контроль модулей в режиме эмуляции среды сервера 1С:Предприятия.
Среди наиболее часто встречающихся ошибок при тестировании работы на сервере 1С:Предприятия, можно выделить следующие:
Вызов метода глобального контекста, который не может быть использован на сервере (например, Предупреждение() ); Создание объекта, который не может быть использован на сервере (например, Цвет);Вызов процедур общего модуля, у которого не установлен признак использования на сервере;Для исправления подобных ошибок следует использовать разрешенные методы, свойства и объекты.
Для исправления подобных ошибок следует установить свойство Сервер общего модуля, либо, если вызываемая процедура используется только на сервере, перенести ее в отдельный общий модуль с установленным свойством Сервер . Также, для исправления подобных ошибок, можно использовать директивы препроцессора, в явном виде указывающие контекст исполнения участка кода.
- Использование переменных, определенных в модуле приложения;
Для исправления подобных ошибок следует использовать параметры сеанса, содержащие аналогичные значения экспортных переменных модуля приложения.
Например: Переменная модуля приложений - глТекущийПользователь и ПараметрСеанса - ТекущийПользователь.
Важно учитывать, что время получения значения параметра сеанса значительно превышает время получения значения переменной модуля приложения. Поэтому, полный отказ от использования переменных модуля приложения в пользу параметров сеанса является неправильным. Следует применять комбинированный метод: - в модулях объектов следует применять только параметры сеанса, поскольку это решит проблему недоступности объектов на сервере - в модулях форм следует применять только переменные модуля приложения, поскольку здесь более важным является быстродействие кода, кроме того модуль формы заведомо не будет выполняться на сервере.
Общие рекомендации
Поставка модулей без исходных текстов
В группе тестов синтаксического контроля модулей представлен также тест создания файлов поставки и обновления. В настройках поставки можно указать поставку модулей объекта без исходных текстов, однако для того чтобы воспользоваться этой возможностью, модуль не должен содержать директив препроцессора, что и проверяется этим тестом.
Логическая проверка модулей
Представляет собой набор дополнительных (не связанных с синтаксическим контролем) тестов модулей.
Поиск неиспользуемых процедур и функций
Сами по себе неиспользуемые (никогда не вызываемые) процедуры и функции ошибкой не являются, однако их наличие может косвенно свидетельствовать об ошибках в логике конфигурации. В частности, с помощью этого теста можно найти потерянные, в том числе и случайно, обработчики событий элементов управления в формах.
Самой главной особенностью этого теста является то, что анализ использования выполняется в пределах модуля, где данная процедура расположена, дополнительно анализируется возможное использование процедуры в качестве обработчика какого-либо события. Процедуры и функции, которые объявлены как экспортные, никогда не считаются неиспользуемыми. Это связано с их возможным вызовом из внешнего соединения. Поэтому невозможно использовать данный тест для обнаружения потерянных обработчиков команд интерфейсов, поскольку такие обработчики должны быть объявлены как экспортные.
Следует учитывать, что в некоторых случаях определение процедуры или функции как неиспользуемой может выполняться некорректно. Это относится к случаям динамического назначения обработчиков событий при помощи объекта Действие и методов УстановитьДействие() и ПодключитьОбработчикОжидания() .
Проверка существования назначенных обработчиков
Проверяется существование обработчиков, на которые ссылаются элементы управления в формах, команды в интерфейсах и элементы графических схем.
Полезность этого теста заключается в том, что в режиме 1С:Предприятие отсутствие обработчика не вызовет ошибки, - просто ничего не будет выполнено. В итоге локализация ошибки конфигурации может быть затруднена.
Поиск пустых обработчиков
Пустой (ничего не исполняющий) обработчик события формально не является ошибкой, однако наличие таких обработчиков может негативно сказаться на производительности конфигурации, особенно если соответствующее событие возникает регулярно, например событие При выводе строки табличного поля.
"На текущий момент существует два способа применения расширений конфигурации.
Без анализа структур данных (быстрый): используется когда гарантированно нет изменения структур данных
С анализом структур данных. Способ гораздо дольше, так как уже требует совмещать расширение с основной конфигурацией и проводить достаточно много проверок.
Определение способа производится предварительным анализом в начале применения. Анализ должен быть быстрым и поэтому использует достаточно грубый метод - анализируется может ли измененный объект влиять на структуры данных. Так как изменение модуля документа так же отмечает сам документ как измененный то, это приводит к применению такого расширения по долгому пути. При изменении общего модуля применение соответственно будет происходит быстро. Мы планируем улучшить ситуацию, но пока так.
Как обходной путь для расширений, не меняющих структуры данных, пока можно предложить понизить режим совместимости расширения конфигурации (только расширения) до версии 8.3.10. Это гарантирует применение расширения быстрым способом (так как в нем точно нет изменений, влияющих на структуры данных)."
Буду пробовать понижать версию совместимости.
Э. А простите, вопросы к страдающим:
- проверка идет в режиме конфигуратора, т.е. у вас происходит режим разработчика и жалобы на проверку расширения в этом режиме?
- или вы готовое расширение накатываете на боевую базу и жалуетесь уже на боевой базе?
Надеюсь, что намек достаточно прозрачный
(9) Спрашивается, нахрена делать проверку метаданных, если эти метаданные не изменялись ни в основной конфигурации, ни в расширении? Если я модуль добавил или реквизит какой - хрен с вами, проверяйте. Но постоянно-то при каждой записи изменений конфигурации зачем?
Надеюсь, что намёк достаточно прозрачный?
С рабочей базой проблема не волнует. Рабочая обновляется раз в день в отличии от работы разработчика в базе разработчика. На рабочей ненапряжно и подождать. Если, конечно, процесс занимает не десятки минут и больше.
"На текущий момент существует два способа применения расширений конфигурации.
Без анализа структур данных (быстрый): используется когда гарантированно нет изменения структур данных
С анализом структур данных. Способ гораздо дольше, так как уже требует совмещать расширение с основной конфигурацией и проводить достаточно много проверок.
Определение способа производится предварительным анализом в начале применения. Анализ должен быть быстрым и поэтому использует достаточно грубый метод - анализируется может ли измененный объект влиять на структуры данных. Так как изменение модуля документа так же отмечает сам документ как измененный то, это приводит к применению такого расширения по долгому пути. При изменении общего модуля применение соответственно будет происходит быстро. Мы планируем улучшить ситуацию, но пока так.
Как обходной путь для расширений, не меняющих структуры данных, пока можно предложить понизить режим совместимости расширения конфигурации (только расширения) до версии 8.3.10. Это гарантирует применение расширения быстрым способом (так как в нем точно нет изменений, влияющих на структуры данных)."
Буду пробовать понижать версию совместимости.
Э. А простите, вопросы к страдающим:
- проверка идет в режиме конфигуратора, т.е. у вас происходит режим разработчика и жалобы на проверку расширения в этом режиме?
- или вы готовое расширение накатываете на боевую базу и жалуетесь уже на боевой базе?
Надеюсь, что намек достаточно прозрачный
(9) Спрашивается, нахрена делать проверку метаданных, если эти метаданные не изменялись ни в основной конфигурации, ни в расширении? Если я модуль добавил или реквизит какой - хрен с вами, проверяйте. Но постоянно-то при каждой записи изменений конфигурации зачем?
Надеюсь, что намёк достаточно прозрачный?
С рабочей базой проблема не волнует. Рабочая обновляется раз в день в отличии от работы разработчика в базе разработчика. На рабочей ненапряжно и подождать. Если, конечно, процесс занимает не десятки минут и больше.
"На текущий момент существует два способа применения расширений конфигурации.
Без анализа структур данных (быстрый): используется когда гарантированно нет изменения структур данных
С анализом структур данных. Способ гораздо дольше, так как уже требует совмещать расширение с основной конфигурацией и проводить достаточно много проверок.
Определение способа производится предварительным анализом в начале применения. Анализ должен быть быстрым и поэтому использует достаточно грубый метод - анализируется может ли измененный объект влиять на структуры данных. Так как изменение модуля документа так же отмечает сам документ как измененный то, это приводит к применению такого расширения по долгому пути. При изменении общего модуля применение соответственно будет происходит быстро. Мы планируем улучшить ситуацию, но пока так.
Как обходной путь для расширений, не меняющих структуры данных, пока можно предложить понизить режим совместимости расширения конфигурации (только расширения) до версии 8.3.10. Это гарантирует применение расширения быстрым способом (так как в нем точно нет изменений, влияющих на структуры данных)."
Буду пробовать понижать версию совместимости.
Э. А простите, вопросы к страдающим:
- проверка идет в режиме конфигуратора, т.е. у вас происходит режим разработчика и жалобы на проверку расширения в этом режиме?
- или вы готовое расширение накатываете на боевую базу и жалуетесь уже на боевой базе?
Надеюсь, что намек достаточно прозрачный
(9) Спрашивается, нахрена делать проверку метаданных, если эти метаданные не изменялись ни в основной конфигурации, ни в расширении? Если я модуль добавил или реквизит какой - хрен с вами, проверяйте. Но постоянно-то при каждой записи изменений конфигурации зачем?
Надеюсь, что намёк достаточно прозрачный?
С рабочей базой проблема не волнует. Рабочая обновляется раз в день в отличии от работы разработчика в базе разработчика. На рабочей ненапряжно и подождать. Если, конечно, процесс занимает не десятки минут и больше.
Не смог найти информации по надписи при обновлении:
Проверка корректности метаданных.
Конфигурация весит около 270 МБ. При изменении текста модулей запускаю отладку. После этого запуск базы идет в течении 40+ секунд.
Основное время которое висит окно это "Проверка корректности метаданных". Что с этим можно сделать?
Сейчас конфигурация 8.3.5, платформа 8.3.8. Раньше была платформа 8.3.5 и конфигурация 8.2.13, тогда база запускалась быстрее после изменения кода примерно 7 секунд.
Как ускорить запуск отладки после изменения конфигурации?
Проверка корректности метаданных, которая выполняется при обновлении конфигурации, выполняется неоправданно долго.
Что на партнерском написали не знаю!
(1) Вроде нормально для 1С, разве нет?
Файловая база или на сервере?
Хранилище для коллективной разработки подключено?
(5) Значит, мне известно, что файл с деревом в конфигураторе можно получить в расшифрованном виде в считанные доли секунд, но 1С тратит на это не простительно много времени. Делаем вывод, 1С прочитывает лишнее, когда открываем конфигурацию. Поэтому с большим количеством объектов страшные тормоза.
Проверка этого факта доступна через трассировку запросов к SQL серверу. Увидим, что читаются целиком таблицы конфига и параметров (и прочие с описаловом)
(5) изменение конфигурации предполагает перегенерацию конфига и параметров (вместе с прочим описаловом) на основе саве конфига.
Пробуем просто прочитать и расшифровать конфиг, параметры и прочее описалово. В результате устаем ждать конца процедуры. Делаем вывод - 1С звездит не оптимальными алгоритмами, а объем огромен.
Значит сохранение конфигурации будет весьма долгим.
При изменении текста модулей запускаю отладку. После этого запуск базы идет в течении 40+ секунд.Основное время которое висит окно это "Проверка корректности метаданных". Что с этим можно сделать?
Аналогичная ситуация, только с "новой" платформой.8.3.12.1714 (клиент-серверная база).
Изменив всего лишь текст модуля документа и запустив обновление - висит около минуты-двух с "Проверка корректности метаданных".
Кто встречался с проблемой ? Что посоветуете ?
Ну может процессор скромный, а проверки стали более тщательными в новой платформе? Решил протестировать обновление конфигурации базы при различных режимах совместимости:8.3.3
Развернул конфигурацию в файловом режиме и просто в один из модулей добавлял или удалял перенос строки.
Коллеги добрый день! Сталкиваемся с той же проблемой - при сохранении конфигурации висим на "Проверка корректности метаданных. " сервер исключительно для разработчиков за 2 ляма - к нему претензий нет. Конфигурация весит 300 мег, при простом изменении кода запускается 1 мин +. Есть идеи куда копать? (9) запрос в 1С писать не буду. Но дело в явно в новом алгоритме платформы! Чем больше модулей, тем дольше! (10) пока спасаюсь кодированием через расширения но блин такое поведение конфигуратора никуда не годится(((Проверка корректности метаданных, которая выполняется при обновлении конфигурации, выполняется неоправданно долго.
Что на партнерском написали не знаю!
(14) Цитирую пост от 13.07.2017 17:01
Проблема вновь обнаружилась на ERP версии 2.4.1.126, платформа 8.3.10.2375
Внесено незначительное количество изменений в оригинальную конфигурацию, но изменение любого символа в модуле вызывает 60-секундную проверку при сохранении-запуске.
Та же проблема в клиент-серверном варианте, на "исправленной" платформе 8.3.10.2252. На файловом варианте той же базы, проблемы отсутствуют. Та же проблема в обоих вариантах платформа 8.3.10.2561(17) у нас режим совместимости 8.3.8. Проблем не замечал.
Конфигурация БП 3.0 без режима совместимости - конфа голая, ради прикола убрал все модули, т.е. оставил только структуру метаданных, эффект тот же при сохранении висит на "проверка корректности метаданных", тех поддержка пока молчит Платформа 8.3.11.2899 - проблема до сих пор актуальна. Бракоделы.Компиляция программного модуля может выполняться медленно, если в модуле происходит активная работа с метаданными, в которые входят общие реквизиты.
Столкнулся с этой же проблемой в ЕРП на платформе 8.3.8.*.
Существует ли какое-то эффективное решение прjav * ascript:void(0);облемы на текущий момент?
пока спасаюсь расширением и кодю там - когда готово кладу в конфу - но это жуткий танец с бубном и не всегда адекватно работает!Попробовал в файловом режиме на платформе 8.3.10.2252 и у меня получилось обновиться!
В файловом режиме на платформе 8.3.11.2867 программа аварийно вылетает.
Поставить сервер на другую платформу и обновить. Раз на файловой все ок. Удалось ли автору ускорить обновление? Есть положительные итоги? (27) тесты проводились на УСО 1.2 перепиленная это ОФ.
Сейчас работаю с УТ 11.3 на 8.3.10, особо внимания не обращал, но конечно не 5 сек запуск!
Аналогичная база и платформа.
Не хочется плодить темы. Последнее время начал лагать набор текста в конф-ре. Т.е. конфигуратор тупо не успевает за мной, особенно используя подстановки.
Или вот, прямо сейчас, пытаюсь инициализировать строковую переменную - ввожу двойные кавычки - жду 10 секунд, пока конфигуратор сообразит.
Не подскажете, я один такой неудачник?
Такая проблема только с написанием кода внутри конфы, с внешними обработками все ровно - лагов нет.
ЗЫ: Кеш почистил - саморазумеющееся. (29) скорее всего это видео карта. Просите админов обновить драйвера. Диск на беды проверили? (30) встройка от интел (i5 2500). На другом пк пробовал кодить - такая же беда, а на нём даже ssd стоит! Висит при обновлении расширения. Обновление основной конфигурации проходит быстро.
8.3.12.1714
SSD стоит на диске с сервером 1С и tempdb. Базы и TEMP на обычных дисках.
Бесит нереально, срывает сроки. (35) скорее всего работу в режиме 8.3.12 с расширениями не оптимизировали.
Пишите в поддержку, возможно в будущих релизах ускорят.
Надеюсь кому-нибудь поможет моё наблюдение - тоже столкнулись с долгим висением надписи "Проверка корректности метаданных". 1С 8.3.12, Конфигурация КА2, есть расширение, победили так: выгрузили расширение в cfe, полностью удалили расширение из конфигурации, после чего вручную создали расширение, и подгрузили в него сохранённый cfe. Зависание с "Проверка корректности метаданных" ушло (слава Кришне). Возможная причина появления - в процессе обновления КА2 сталкивался с тем, что менялась область действия конфигурации, и как раз после этого и начались подвисания при записи
p.s. Даже с этими болячками роста, расширения - это огромный шаг вперёд и применять их стоит (пока что без данных).
На текущий момент существует два способа применения расширений конфигурации.
Без анализа структур данных (быстрый): используется когда гарантированно нет изменения структур данных
С анализом структур данных. Способ гораздо дольше, так как уже требует совмещать расширение с основной конфигурацией и проводить достаточно много проверок.
Определение способа производится предварительным анализом в начале применения. Анализ должен быть быстрым и поэтому использует достаточно грубый метод - анализируется может ли измененный объект влиять на структуры данных. Так как изменение модуля документа так же отмечает сам документ как измененный то, это приводит к применению такого расширения по долгому пути. При изменении общего модуля применение соответственно будет происходит быстро. Мы планируем улучшить ситуацию, но пока так.
Как обходной путь для расширений, не меняющих структуры данных, пока можно предложить понизить режим совместимости расширения конфигурации (только расширения) до версии 8.3.10. Это гарантирует применение расширения быстрым способом (так как в нем точно нет изменений, влияющих на структуры данных).
Читайте также: