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

docs(db-guide): разрешение ссылочных типов при разборе EPF/ERF

Browse Source 
Замер на реквизите CatalogRef (8.3.24): в базе с подходящей конфигурацией
конфигуратор и ibcmd дают одинаковый результат — имя типа
(cfg:CatalogRef.Валюты). Движок начинает влиять, только когда база не та:
ibcmd оставляет идентификатор типа (<v8:TypeId>), 1cv8 подменяет тип на
xs:string с квалификаторами строки.

Годится только имя типа: оно резолвится по имени и собирается в любой
конфигурации с одноимённым объектом. Идентификатор привязан к исходной
конфигурации — в чужой базе сборка проходит без ошибки, но uuid остаётся
висячим. Оба деградированных варианта молчаливы, поэтому разбирать EPF/ERF
нужно только в базе с подходящей конфигурацией.

Инструкции навыков epf-dump/erf-dump намеренно не меняются: ограничение там
уже сформулировано, а объяснение «что будет, если разобрать в пустой базе»
только провоцирует так делать.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Nick Shirokov
2026-08-01 17:38:13 +03:00
co-authored by Claude Opus 5
parent b92aad519c
commit 2067778ba3
1 changed files with 19 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/db-guide.md
+19 -4
View File
@@ -123,10 +123,25 @@ Claude вызовет `/db-run dev`.
91807 файлов из 91807). Дампы конфигурации, снятые разными движками, сравнимы напрямую.
Это НЕ распространяется на разбор внешних обработок и отчётов (`epf-dump`/`erf-dump`): там результат
определяется не движком, а **базой, в которой идёт разбор**. Если ссылочные типы реквизитов в этой
базе не разрешаются (в конфигурации нет соответствующих объектов), в исходники попадают
идентификаторы вместо имени типа. Поэтому для разбора нужна база с матч-конфигурацией — и при
работе через `ibcmd` за этим надо следить отдельно, чтобы разбор не ушёл в пустую или чужую базу.
определяется **базой, в которой идёт разбор**, а движок начинает влиять, когда база не та.
Замер на реквизите типа `CatalogRef.Валюты` (платформа 8.3.24):
| База разбора | Движок | Что попадает в исходники |
|---|---|---|
| с подходящей конфигурацией | `1cv8` и `ibcmd` одинаково | `<v8:Type>cfg:CatalogRef.Валюты</v8:Type>` |
| без нужного объекта | `ibcmd` | `<v8:TypeId>602d2ea9-…</v8:TypeId>` — идентификатор типа |
| без нужного объекта | `1cv8` | `<v8:Type>xs:string</v8:Type>` + `StringQualifiers Length=10` |
Годится только первая строка, и вот почему. Имя типа резолвится **по имени**: такие исходники
собираются в любой конфигурации, где есть одноимённый объект. Идентификатор же привязан к той
конфигурации, из которой получен: сборка в чужой базе проходит **без ошибки**, но uuid остаётся
висячим и ни к чему не привязывается — работать с такими исходниками нельзя. Вариант с `xs:string`
хуже всех: ссылка подменена строкой, и по XML не видно, что там вообще была ссылка.
Оба деградированных варианта молчаливы — ни при разборе, ни при последующей сборке ошибок нет.
Поэтому разбирать EPF/ERF нужно в базе с подходящей конфигурацией; «разберу в пустой, потом
поправлю» не работает.
Ограничения:
- только **файловые** базы (для серверных используйте конфигуратор);