Open dashiwa opened 5 years ago
Ну при необходимости, можно сделать и транзакции и валидацию..
Но тут тоже думаю, надо плясать от конкретных юзкейсов.
Кстати, когда сильно интересовался данным вопросом (импортом данных в сборку, или деплой контента с дев на продакшн) набредал на кучу решений, но глубоко не копал..
примерный гугл-запрос: drupal 8 content deploy
Думаю, если с этим хорошо разобраться , то можно подобрать какое-то готовое адекватное решение для подобных задач. И с транзакциями и с валидацией и с исправлением ошибок импорта..
Единстенно что мне во всей этой истории с программным импортом данных в drupal 8 не нравится, это то что данный функционал нужен для кучи всяких "дел": импорт, миграция, API доступа к данным (REST и т.п.)
И все его делают по своему. А по идее, структура данных drupal 8 же стандартна.. Можно же разработать какой-то стандарт импорта, например json определенной структуры и разработать API для загрузки этих json-ов в друпал. С танзауциями и с валидацией. А всем остальным "решениям" просто преобразовывать собственные данные к данному стандартному формату и скармливать их API.
@orion76 Немного не то. Это не связано с контентом
Что я нашел - В общем большая часть схемы данных содержится в key_value хранилище в виде сериализованных данных.
Это и схема данных для таблиц энтити и для филдов и конфиги для вьюса и тд. По такому же принципу хранятся данные для роутов в админке.
Код сериализуется , при первом запуске данные читаются с кода, а потом уже с данного хранилища. (такая схема неплохо затрудняет отладку)
Если данные там повредились , логика работает некорректно. Я не нашел механизма очистки этого хранилища в документации. В общем можно чистить и самому. Это решает много проблем
Надеюсь что вопрос с некорректной схемой данных решил. а так ли это покажет практика
Хм.. пока на практике с "повреждением" конфигов не сталкивался.
Глубоко не копал, но вроде все конфиги "перечитываются" из yml и аннотаций при полной очистке кэша.
Про усложнение отладки тоже не до конца понял. Если ты про "посмотреть" текущее значение какого либо параметра какого либо конфига? Мне пока хватало полнотекстового поиска по коду всего проекта или отдельной директории, по маске имени файла, иногда применяя регулярки.
В PHPStorm данная функция доступна по Ctrl+Shift+F отрабатывает за 5-15 секунд
Про усложнение отладки тоже не до конца понял.,
Уже нашел.. Все что пишется в аннотации передается в discover плагин..а тот уже передает лексеру аннотаций а потом это все идет в нужные класс и там уже проверятся чтобы аннотация сопоставлялась нужной переменной класса..
Я имел ввиду что часто данные хранятся в каком-то хранилище, и напрямую из кода не читаются. Кеш, понятно . Но как оказалось есть и еще несколько специфических хранилищь. В общем работая с кодом все это проясняется .
Ну да.. по сути аннотация это тотже конфиг.. который передается в конструктор некоего "плагина", в случае с аннотацией к Entity это плагин ContentEntityType..
А данный плагин предоставляет методы и свойства для доступа к полям аннотации.
например данный плагин инжектится в RouteProivider сущности как EntityTypeInterface $entity_type и предоставляет методы доступа к полям аннотации, например шаблон ссылки из секции links аннотации: $entity_type->getLinkTemplate('version-history')
Кстати, оказывается PHPStorm "понимает" аннотации, и по Ctrl+click по @ContentEntityType в аннотации переходит к реализации данного класса
`
`
@orion76 Задался вопросом. Есть ли в 8ке механизм проверки потерянных или сломанных данных в БД.
Пример - когда мы устанавливаем модуль , производим различные импорты и тд. У нас запускается импорт определенных значений из схемы базы данных на бекенде в БД
Это выполняется нетранзакционно, в результате любой возможной ошибки в цепочке скриптов , мы можем получить сломанные данные , неполный импорт и тд.
Можно ли это отслеживать? Можно ли это чинить автоматически определенным механизмом?