creator/cc-1c-skills
1
0
Fork 0
mirror of https://github.com/Nikolay-Shirokov/cc-1c-skills.git synced 2026-07-27 07:01:02 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs(xdto-guide): рецепт версионной копии пакета вместо описания результата

Browse Source 
Раздел «Новая версия пакета» описывал, что получается, но не как это сделать,
и из-за этого выглядел местом, требующим отдельного флага компилятора. Рутины
там на самом деле немного: выгрузить схему, поменять в шапке targetNamespace
и связанное объявление xmlns, собрать под новым именем — имя и синоним задаются
флагами, править их внутри схемы не нужно.

Названа острая кромка: заменять все вхождения URI строкой нельзя — пострадает
импорт пространства имён, для которого старый URI является префиксом.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Nick Shirokov
2026-07-26 16:33:27 +03:00
co-authored by Claude Opus 5
parent 64b461930b
commit 32455a64b1
1 changed files with 17 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/xdto-guide.md
+17 -4
View File
@@ -113,11 +113,24 @@
Типовой приём: рядом со старым пакетом появляется новый с другим пространством
имён (`EnterpriseData_1_19` → `_1_20`), а старые потребители продолжают смотреть
на прежний namespace.
на прежний namespace. Копия делается через выгрузку схемы и сборку под новым именем:
Если же надо сменить namespace **у существующего** пакета, агент перепишет все
внутренние ссылки и перечислит пакеты, которые импортируют старый — но менять
их не станет, потому что при версионировании это было бы ошибкой.
1. `/xdto-decompile` исходного пакета в файл схемы;
2. в схеме поменять `targetNamespace` — **и связанное с ним объявление `xmlns`**,
которым внутренние ссылки пользуются как префиксом;
3. `/xdto-compile` этой схемы с `-Name` нового пакета (имя и синоним задаются
флагами, править их внутри схемы не нужно).
Внутренние ссылки при этом переводятся на новый namespace целиком, импорты чужих
пакетов сохраняются, исходный пакет не меняется.
Менять `targetNamespace` **заменой всех вхождений строки** — плохая идея: если пакет
импортирует пространство имён, у которого старый URI является префиксом
(`urn:example:exchange` и `urn:example:exchange:legacy`), заменится и оно.
Если же надо сменить namespace **у существующего** пакета, а не сделать копию, агент
перепишет все внутренние ссылки и перечислит пакеты, которые импортируют старый — но
менять их не станет, потому что при версионировании это было бы ошибкой.
### Отдать схему контрагенту