И OScript'a!

В ответ таки тоже обкритиковали

библиотеку флюента уже можно в 1Ске использовать?

Надо кстати попробовать портировать

Тебя там в ответ обкритиковали 😂

Ага, норм.

Коллеги, привет. Такой вопрос. Выгружаю конфигурацию в файлы в пустую папку. Выгрузка конфигурации происходит с ключом update, как в статье https://wonderland.v8.1c.ru/blog/inkrementalnaya-vygruzka-konfiguratsii-v-xml/ . Первый раз, понятно, происходит долгая выгрузка, потом с остальными выгрузками, когда файл ConfigDumpInfo пристуствует после 1 выгрузки, сравнивается файлик ConfigDumpInfo.xml, и выгрузка происходит только по объектам, которые были изменены. Но, есть нюанс. Когда переименовываешь реквизит, или удаляешь форму, то 1С делает изменение в ConfigDumpInfo и меняет ConfigVersion.(скрин ниже). Из-за которого выгрузка снова происходит целиком, а не по измененным объектам. Если же добавляю новые реквизиты, регистры и вообще любые объекты, то ConfigVersion не меняется. Вопрос, как это победить? Есть какая-то настройка может быть?

Раньше оно вообще на любое изменение метаданных делало полную выгрузку
Так что уже лучше, что при добавлении нет полной выгрузки :)

это воскресший из 8.3.12 баг. В 1С я его снова отправил.

кто-то нашел Выполнить

Меня вообще очень умиляет, когда в заголовке таких статей пишут про функции как объекты первого класса и что жить без этого невозможно, а рядом же через строчку начинают приводить примеры с анонимными функциями и лямбдами строкой. Так и хочется написать RTFM.

там еще ООП к этому прикрутили

это ещё и документацию чтоли читать? Некогда, надо лямбды пилить

Друзья, в платформе как-нибудь можно избавиться от длительных неявных возвратов больших ТЧ с сервера на клиент (в контекстных вызовах сервера)?

Есть форма объекта, где в ТЧ несколько тысяч строк. На форму для теста добавил две кнопки-команды с пустыми обработчиками: одна вызывает сервер с контекстом, другая - без. Ставлю точку останова в конце обоих серверных методов.
Без контекста возврат на клиента происходит мгновенно, с контекстом - через секунд 10. При этом в объекте на клиенте ничего не менял, просто открыл и нажимаю эту пару кнопок.

В итоге большая ТЧ замедляет каждый контекстный серверный вызов, большинство которых вообще не связано с работой с этой ТЧ :(

Переделать ТЧ на ДС-регистр (хранение данных и их отображение) будет весьма трудозатратно, но пока пришел к выводу, что это единственный более-менее хороший вариант.
Альтернативой видится переделывать остальные контекстные вызовы на неконтекстные, но в большинстве случаев для этого придется передавать на сервер содержимое других ТЧ и реквизитов, получение и сериализация которых тоже будет отъедать значительное время, что в сумме может превысить выгоду от экономии невозврата одной большой ТЧ...

Может, есть еще идеи?

Похожую ситуацию нашел, но там вроде тот же самый вердикт: https://forum.infostart.ru/forum9/topic227479/

Вообще, разработчики неоднократно обещали при серверном вызове отдавать только измененные строки ТЧ. Однако сам я ни разу не наблюдал, чтобы это было так. По ощущениям - форма ездит всегда целиком, даже если ее не меняли

Конечно можно.
- не делать большие ТЧ
- рс можно, но сложно будет реализация объектной логики в динамическом списке. Если вычитывать в ТЗ - будут те же Фаберже.
- отказаться от контекстных вызовов. Это вообще просто. Абсолютно любые расчеты, отборы и т.п. решаются без контекста. Проблема будет только в открытии и записи по паре минут, если строк в сотни тысяч

На платформе 8.3.13.1644 типовая форма подбора в документ списания работала 12 сек. Перенесли базу на 8.3.18.1483 стало 2 сек.