Действия схемы#

Область действия#

• Действия определяют lifecycle-операции для library-scoped сущностей схемы: пользовательские типы, пользовательские подтипы и пользовательские поля.
• Сущности схемы используют внутренние стабильные key, уникальные в рамках одной библиотеки.

Действия для типов#

• create-type

  • Создает пользовательский тип контента в текущей библиотеке.
  • Внутренний key ДОЛЖЕН быть уникальным в библиотеке.

• edit-type

  • Обновляет редактируемые свойства типа.
  • Внутренний key ДОЛЖЕН оставаться неизменяемым.

• archive-type / unarchive-type

  • Отключает/включает тип для активного использования в новых записях.
  • Существующие записи с этим типом остаются валидными.

• delete-type

  • Hard delete допустим только если на тип не завязаны записи/подтипы/схемы полей.
  • Иначе операция ДОЛЖНА отклоняться или требовать явную миграцию.

Действия для подтипов#

• create-subtype

  • Создает подтип внутри выбранного типа.
  • Внутренний key ДОЛЖЕН быть уникальным в scope родительского типа.

• edit-subtype

  • Обновляет редактируемые свойства подтипа.
  • Внутренний key ДОЛЖЕН оставаться неизменяемым.

• archive-subtype / unarchive-subtype

  • Отключает/включает подтип для активного использования в новых записях.
  • Существующие записи с этим подтипом остаются валидными.

• delete-subtype

  • Hard delete допустим только если на подтип не завязаны записи/схемы полей.
  • Иначе операция ДОЛЖНА отклоняться или требовать явную миграцию.

Действия для схем полей#

• create-field

  • Создает пользовательское поле, привязанное к scope типа или подтипа.
  • field_type ДОЛЖЕН выбираться только из списка разрешенных типов полей.

• edit-field

  • Обновляет редактируемые атрибуты поля (name, required, default, validation, visibility/order).
  • Внутренний key ДОЛЖЕН оставаться неизменяемым.
  • Прямое изменение field_type через edit-field НЕ ДОЛЖНО применяться.

• archive-field / unarchive-field

  • Отключает/включает поле для активного использования в формах.
  • Существующие сохраненные значения остаются валидными.

• delete-field

  • Hard delete допустим только при явном подтверждении удаления данных или после миграции зависимых значений.
  • Операция ДОЛЖНА сохранять целостность данных и ссылок.

Правило миграции#

• Любое изменение field_type ДОЛЖНО выполняться как явная migration-операция.
• Migration flow обязателен всегда для изменений field_type, даже если значений поля пока нет.
• Migration flow ДОЛЖЕН создавать/назначать target-тип поля, выполнять конвертацию и применять результат только после явного подтверждения.
• Предпроверка migration ДОЛЖНА показывать отчет по затронутым записям.
• Migration-операция ДОЛЖНА выдавать отчет по затронутым записям и итоговому статусу.

Базовые переходы field_type#

• Переходы типов полей делятся на safe, conditional и forbidden.

Safe-переходы:

• text -> long_text
• integer -> decimal
• date -> datetime
• ref -> ref_list

Conditional-переходы:

• long_text -> text
• decimal -> integer
• datetime -> date
• text -> integer | decimal | date | datetime | duration | url | email | phone
• text <-> enum | multi_enum
• ref_list -> ref
• json -> any
• any -> json

Forbidden-переходы:

• ref | ref_list -> numeric | date | boolean
• enum | multi_enum -> ref | ref_list
• file_ref -> numeric | date | boolean

Политика для conditional-переходов:

• Migration ДОЛЖНА предлагать явный выбор политики для conditional-переходов.
• Baseline варианты политики: fail_on_error или set_null_on_error.

Правило границы библиотеки#

• Действия схемы являются library-scoped.
• Cross-library изменения схемы запрещены.