Загрузка расширения из XML: "Дублирование имени объекта метаданных:" для всех реквизитов в расширении
Веду свои доработки конфигурации на поддержке; всё, что возможно, делаю через расширения. Поставщик конфигурации также иногда присылает изменения к одному из моих расширений, отражающие изменения в очередном обновлении основной конфигурации. Слияние изменений делаю средствами Git (через TortoiseGit), т.к. 1С не умеет делать трехстороннее слияние. Для корректного слияния XML-файлов взял .
Обычно сливаемые изменения невелики, и слитый код успешно работает. Но сейчас я слил серьезную доработку, и при попытке загрузить получившимйся код в конфигуратор возникли нижеуказанные сабжевые ошибки.
Платформа 8.3.23.1865 x64, режим совместимости 8.3.17 .
Всего около 100 строк. Похоже, это вообще все реквизиты в расширении -- и заимствованные, и даже добавленные -- которые и сопоставлять-то не с чем!
Мерджил ветку проекта в основную ветку; если был конфликт изменений в UUIDах объектов, я брал тот, что в основной ветке (т.е. оставлял без изменений).
Файл ConfigDumpInfo.xml удаляю.
Гугление показывает, что эта ошибка бывает, когда конфигуратор не может сопоставить существующие объекты с загружаемыми: , , .
Однако, я изучил механизм сопоставления и проверил, что всё, что можно, вроде бы совпадает (см. ниже).
Еще одно различие: в найденных результатах говорится только про обновление основной конфигурации, и ошибка происходит при обновлении конфигурации БД. Тогда как у меня -- расширение, и ошибка происходит прямо при загрузке из XML, еще до попытки обновления конфигурации БД. Таких случаев не нагуглил.
* Согласно , объекты сопоставляются:
* по внутреннему идентификатору -- по-видимому, атрибут "uuid" в теге описание объекта метаданных. В расширении содержимое тега "<ExtendedConfigurationObject>", по-видимому, является ссылкой на расширяемый объект
* по имени, если в св-вах расширения не выставлена галочка "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам" (у меня она везде выставлена).
Я проверил, что соответствующие имена и идентификаторы в основной конфигурации и расширении совпадают. Вот, например, справочник "КарточкиВспомогательногоОборудования" в расширении:
и он же в основной конфигурации (вложено).
---
Пробовал:
1. В версии расширения в тестовой базе добавить нужные реквизиты, выгрузить в тот же каталог и посмотреть изменения.
* В вышеуказанный файл выгрузилось то же самое, но реквизиты были в другом порядке и UUID у ЗаводскойНомер был другой. Я поменял в исходном файле и UUID, и порядок -- та же самая ошибка.
2. Переименовать реквизиты с ошибками. Получил кучу ошибок "неверно указан путь к данным" (где на эти реквизиты ссылаются по имени), после исправления путей -- та же ошибка, но уже с новыми именами.
3. Исправить даты всех файлов, на случай если конфигуратор хочет, чтобы что-то из них было старее/новее чего-то. Делал через "git ls-tree -r HEAD --name-only -z | xargs -0 touch" из командной строки Git Bash. Та же ошибка.
4. Исправить концы строк во всех файлах на CRLF через "git ls-tree -r HEAD --name-only -z | xargs -0 u2d" (у меня они после мерджа оказались LF, т.к. в Git for Windows я еще давно, при установке, по умолчанию выставил "core.autocrlf=input"). Та же ошибка.
5. В Configuration.xml в "<KeepMappingToExtendedConfigurationObjectsByIDs>" (состояние галочки "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам") выставить в false, а во всех файлах удалить теги "<ExtendedConfigurationObject>", чтобы заставить конфигуратор сравнивать по имени. Та же ошибка.
6. Почистить кэш 1с (закрыть все клиенты, удалить папки "%APPDATA%\1C\1cv8\<uuid>" и "%LOCALAPPDATA%\1C\1cv8\<uuid>"). Та же ошибка.
---
Все это явно свидетельствует о том, что в механизме сопоставления есть еще какая-то "секретная" проверка, не описанная в статье ИТС, о которой я не знаю. В есть ссылка на партнерский форум, где якобы "всё объясняется", но что именно там объясняется -- неизвестно.
Обычно сливаемые изменения невелики, и слитый код успешно работает. Но сейчас я слил серьезную доработку, и при попытке загрузить получившимйся код в конфигуратор возникли нижеуказанные сабжевые ошибки.
Платформа 8.3.23.1865 x64, режим совместимости 8.3.17 .
Справочник.КарточкиВспомогательногоОборудования.Реквизит.ИнвентарныйНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиИспытательногоОборудования.Реквизит.ЗаводскойНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиИспытательногоОборудования.Реквизит.ИнвентарныйНомер - Дублирование имени объекта метаданных:
Справочник.КарточкиВспомогательногоОборудования.Реквизит.ЗаводскойНомер - Дублирование имени объекта метаданных:
<...>
Справочник.КарточкиСредствИзмерений.Реквизит.Акр_НаименованиеПолное - Дублирование имени объекта метаданных:
<...>Всего около 100 строк. Похоже, это вообще все реквизиты в расширении -- и заимствованные, и даже добавленные -- которые и сопоставлять-то не с чем!
Мерджил ветку проекта в основную ветку; если был конфликт изменений в UUIDах объектов, я брал тот, что в основной ветке (т.е. оставлял без изменений).
Файл ConfigDumpInfo.xml удаляю.
Гугление показывает, что эта ошибка бывает, когда конфигуратор не может сопоставить существующие объекты с загружаемыми: , , .
Однако, я изучил механизм сопоставления и проверил, что всё, что можно, вроде бы совпадает (см. ниже).
Еще одно различие: в найденных результатах говорится только про обновление основной конфигурации, и ошибка происходит при обновлении конфигурации БД. Тогда как у меня -- расширение, и ошибка происходит прямо при загрузке из XML, еще до попытки обновления конфигурации БД. Таких случаев не нагуглил.
* Согласно , объекты сопоставляются:
* по внутреннему идентификатору -- по-видимому, атрибут "uuid" в теге описание объекта метаданных. В расширении содержимое тега "<ExtendedConfigurationObject>", по-видимому, является ссылкой на расширяемый объект
* по имени, если в св-вах расширения не выставлена галочка "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам" (у меня она везде выставлена).
Я проверил, что соответствующие имена и идентификаторы в основной конфигурации и расширении совпадают. Вот, например, справочник "КарточкиВспомогательногоОборудования" в расширении:
<?xml version="1.0" encoding="UTF-8"?>
<Met aDataObject xmlns="http://v8.1c.ru/8.3/MDClasses" xmlns:app="http://v8.1c.ru/8.2/managed-application/core" xmlns:cfg="http://v8.1c.ru/8.1/data/enterprise/current-config" xmlns:cmi="http://v8.1c.ru/8.2/managed-application/cmi" xmlns:ent="http://v8.1c.ru/8.1/data/enterprise" xmlns:lf="http://v8.1c.ru/8.2/managed-application/logform" xmlns:style="http://v8.1c.ru/8.1/data/ui/style" xmlns:sys="http://v8.1c.ru/8.1/data/ui/fonts/system" xmlns:v8="http://v8.1c.ru/8.1/data/core" xmlns:v8ui="http://v8.1c.ru/8.1/data/ui" xmlns:web="http://v8.1c.ru/8.1/data/ui/colors/web" xmlns:win="http://v8.1c.ru/8.1/data/ui/colors/windows" xmlns:xen="http://v8.1c.ru/8.3/xcf/enums" xmlns:xpr="http://v8.1c.ru/8.3/xcf/predef" xmlns:xr="http://v8.1c.ru/8.3/xcf/readable" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.16">
<Catalog uuid="c753dfbd-c5c5-481f-94f3-8d8349c6893b">
<InternalInfo>
<xr:GeneratedType name="CatalogObject.КарточкиВспомогательногоОборудования" category="Object">
<xr:TypeId>3312d372-f8c0-42c1-974c-da6311423da6</xr:TypeId>
<xr:ValueId>b7817bb3-ba2b-4a9a-bfd1-07e604477f14</xr:ValueId>
</xr:GeneratedType>
<xr:GeneratedType name="CatalogRef.КарточкиВспомогательногоОборудования" category="Ref">
<xr:TypeId>ca5a6b0b-96ea-4b66-9d64-4a4cbd46e2f8</xr:TypeId>
<xr:ValueId>cfd1bb86-e977-42f3-92ad-2c33c21ce4b7</xr:ValueId>
</xr:GeneratedType>
<xr:GeneratedType name="CatalogSelection.КарточкиВспомогательногоОборудования" category="Selection">
<xr:TypeId>0aed4560-82d4-41b0-90c7-b9bb8faab816</xr:TypeId>
<xr:ValueId>8f618d65-bb38-4838-a794-02291a397ba0</xr:ValueId>
</xr:GeneratedType>
<xr:GeneratedType name="CatalogList.КарточкиВспомогательногоОборудования" category="List">
<xr:TypeId>8e1703f7-8773-4cad-85ab-557b97093106</xr:TypeId>
<xr:ValueId>872fd1e4-c283-4140-84d1-5a7f60f0812f</xr:ValueId>
</xr:GeneratedType>
<xr:GeneratedType name="CatalogManager.КарточкиВспомогательногоОборудования" category="Manager">
<xr:TypeId>8b6e9fda-9ece-4686-b500-e6eea3e97ec4</xr:TypeId>
<xr:ValueId>94c7ecfe-af17-4f9a-9c54-cf84295328fd</xr:ValueId>
</xr:GeneratedType>
</InternalInfo>
<Properties>
<Ob jectBelonging>Adopted</ObjectBelonging>
<Name>КарточкиВспомогательногоОборудования</Name>
<Comment/>
<ExtendedConfigurationObject>cf84e18c-c2f1-4946-9286-2b15156ea59f</ExtendedConfigurationObject>
</Properties>
<ChildObjects>
<Attribute uuid="46bdb39e-0d57-4b1a-818a-d279e310d2d8">
<InternalInfo/>
<Properties>
<Ob jectBelonging>Adopted</ObjectBelonging>
<Name>ЗаводскойНомер</Name>
<Comment/>
<ExtendedConfigurationObject>82347cd4-7ead-4229-8eb8-c39b0d134a18</ExtendedConfigurationObject>
<Type>
<v8:Type>xs:string</v8:Type>
<v8:StringQualifiers>
<v8:Length>150</v8:Length>
<v8:AllowedLength>Variable</v8:AllowedLength>
</v8:StringQualifiers>
</Type>
</Properties>
</Attribute>
<Attribute uuid="ba345638-7f8a-4f37-86b6-51616b77cc36">
<InternalInfo/>
<Properties>
<Ob jectBelonging>Adopted</ObjectBelonging>
<Name>ИнвентарныйНомер</Name>
<Comment/>
<ExtendedConfigurationObject>dd0db51f-b642-4385-adfe-62bc0751cd65</ExtendedConfigurationObject>
<Type>
<v8:Type>xs:string</v8:Type>
<v8:StringQualifiers>
<v8:Length>150</v8:Length>
<v8:AllowedLength>Variable</v8:AllowedLength>
</v8:StringQualifiers>
</Type>
</Properties>
</Attribute>
</ChildObjects>
</Catalog>
</MetaDataObject>
Показатьи он же в основной конфигурации (вложено).
---
Пробовал:
1. В версии расширения в тестовой базе добавить нужные реквизиты, выгрузить в тот же каталог и посмотреть изменения.
* В вышеуказанный файл выгрузилось то же самое, но реквизиты были в другом порядке и UUID у ЗаводскойНомер был другой. Я поменял в исходном файле и UUID, и порядок -- та же самая ошибка.
2. Переименовать реквизиты с ошибками. Получил кучу ошибок "неверно указан путь к данным" (где на эти реквизиты ссылаются по имени), после исправления путей -- та же ошибка, но уже с новыми именами.
3. Исправить даты всех файлов, на случай если конфигуратор хочет, чтобы что-то из них было старее/новее чего-то. Делал через "git ls-tree -r HEAD --name-only -z | xargs -0 touch" из командной строки Git Bash. Та же ошибка.
4. Исправить концы строк во всех файлах на CRLF через "git ls-tree -r HEAD --name-only -z | xargs -0 u2d" (у меня они после мерджа оказались LF, т.к. в Git for Windows я еще давно, при установке, по умолчанию выставил "core.autocrlf=input"). Та же ошибка.
5. В Configuration.xml в "<KeepMappingToExtendedConfigurationObjectsByIDs>" (состояние галочки "Поддерживать соответствие объектам расширяемой конфигурации по внутренним идентификаторам") выставить в false, а во всех файлах удалить теги "<ExtendedConfigurationObject>", чтобы заставить конфигуратор сравнивать по имени. Та же ошибка.
6. Почистить кэш 1с (закрыть все клиенты, удалить папки "%APPDATA%\1C\1cv8\<uuid>" и "%LOCALAPPDATA%\1C\1cv8\<uuid>"). Та же ошибка.
---
Все это явно свидетельствует о том, что в механизме сопоставления есть еще какая-то "секретная" проверка, не описанная в статье ИТС, о которой я не знаю. В есть ссылка на партнерский форум, где якобы "всё объясняется", но что именно там объясняется -- неизвестно.
Прикрепленные файлы:
КарточкиВспомогательногоОборудования.xml
По теме из базы знаний
- Инфостарт. Восьмерка. Лучшее
- Выгрузка-загрузка любых данных (и измененных) между похожими конфигурациями (ФАЙЛ, HTTP, COM) ЛЮБЫХ баз 1С 8.1-8.3 с обработкой и поиском данных по произвольным полям поиска
- Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С
- Универсальная обработка для 1С 8.3 Инструмент для изменения и исправления ошибок информационной базы
- Универсальные инструменты 1С
Найденные решения
Локализовал проблему постепенным выкидыванием файлов из расширения и "грязным" исправлением ошибок, не относящихся к титульной (т.к. мне было нужно только обеспечить, чтобы алгоритм загрузчика смог проработать до шага, на котором возникает титульная ошибка).
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
<ChildObjects>
<Catalog>Акр_РолиИсполнителейАккредитации</Catalog>
<Catalog>ВидыКонтактнойИнформации</Catalog>
<Catalog>ВидыРабот</Catalog>
<Catalog>ГРСИ</Catalog>
<Catalog>ГРСИ</Catalog>
<Catalog>ВидыРабот</Catalog>
<Catalog>ГруппыДоступаКарточекОборудования</Catalog>
<Catalog>ВидыДеятельности</Catalog>
<Catalog>АвтономныеИзмерительныеБлокиСредствИзмерений</Catal Показать
(5) Техподдержка Oso XML Merge рассказала, как обрабатывать такой случай.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Потому что 1С не умеет делать трехстороннее объединение. Даже EDT (в котором от Eclipse встроенная поддержка Git) не умеет.
Если есть независимые изменения в 2 ветках, при объединении через конфигуратор половина изменений пропадает.
Единственный предлагаемый способ этого избежать -- объединять все такие места руками. Крайне трудозатратно и рискуя где-нибудь ошибиться и получить скрытый баг.
Если есть независимые изменения в 2 ветках, при объединении через конфигуратор половина изменений пропадает.
Единственный предлагаемый способ этого избежать -- объединять все такие места руками. Крайне трудозатратно и рискуя где-нибудь ошибиться и получить скрытый баг.
Также попробовал:
7. Загрузить XML в другое расширение -- на случай, если конфигуратор сравнивает не только с основной конфигурацией, но и с тем, что уже было в расширении.
8. Снять конфигурацию с поддержки, удалить все расширения, обновить конфигурацию БД, и загрузить XML в новое расширение -- на случай, если в сопоставлении участвуют какие-либо другие экземпляры конфигурации, кроме конфигурации разработчика.
Сейчас буду локализовывать проблему далее.
7. Загрузить XML в другое расширение -- на случай, если конфигуратор сравнивает не только с основной конфигурацией, но и с тем, что уже было в расширении.
8. Снять конфигурацию с поддержки, удалить все расширения, обновить конфигурацию БД, и загрузить XML в новое расширение -- на случай, если в сопоставлении участвуют какие-либо другие экземпляры конфигурации, кроме конфигурации разработчика.
Сейчас буду локализовывать проблему далее.
Локализовал проблему постепенным выкидыванием файлов из расширения и "грязным" исправлением ошибок, не относящихся к титульной (т.к. мне было нужно только обеспечить, чтобы алгоритм загрузчика смог проработать до шага, на котором возникает титульная ошибка).
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
(Например: ссылки на выкидываемые типы вида "cfg:<....>" заменял на "xs:boolean".)
В Configuration.xml в "<ChildObjects>" дублировались записи. Загрузчик это не проконтролировал и выдал ошибку далее по алгоритму.
Косяк возник потому, что Configuration.xml -- единственный файл, который я не смог объединить через Oso XML Merge.
В этой утилите правила сравнения (=правила поиска тегов, соответствующих друг другу, т.е., фактически, схема) задаются по корневому тегу файла, а у Configuration.xml он такой же, как у файлов других объектов метаданных, но XML-схема совсем другая.
Буду писать разработчикам утилиты, чтобы научили ее как-то поддерживать такой случай.
<ChildObjects>
<Catalog>Акр_РолиИсполнителейАккредитации</Catalog>
<Catalog>ВидыКонтактнойИнформации</Catalog>
<Catalog>ВидыРабот</Catalog>
<Catalog>ГРСИ</Catalog>
<Catalog>ГРСИ</Catalog>
<Catalog>ВидыРабот</Catalog>
<Catalog>ГруппыДоступаКарточекОборудования</Catalog>
<Catalog>ВидыДеятельности</Catalog>
<Catalog>АвтономныеИзмерительныеБлокиСредствИзмерений</Catal Показать
(5) Техподдержка Oso XML Merge рассказала, как обрабатывать такой случай.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.
* В настройках слияния для Configuration.xml задал шаблон имени файла "Configuration*.xml".
** т.к. Git при формировании файлов для внешней программы слияния дает именам суффиксы, но сохраняет расширения
* В файле настроек для прочих стоит "*.xml".
Теперь при слиянии Configuration.xml Oso XML Merge спрашивает, какими настройками воспользоваться.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот