YiiFramework Паттерн проектирования от схемы данных. Есть ли в Yii?

[magnuz]

Есть ли такие расширения чтобы разрабатывать по паттерну "От схемы данных", а не традиционно для yii "От базы"? То есть разрабатываешь в неком виде схему сущностей и связей между ними и по этой схеме создается БД, модели и пр.

 

[hell0w0rd]

Так не бывает. Схема == база. Видимо тебе нужно гуглить в сторону миграций с удобным qb для построения схемы.

 

[Вурдалак]

Что значит не бывает? Чувак хочет, чтобы он описывал метаданные в конфиге (YAML, XML, etc.) и все остальное генерилось бы. Такое бывает, но по поводу Yii ниче не знаю.

 

[hell0w0rd]

Вурдалак, ну так я и говорю, он хочет схему описать каким-то особым методом, от этого она не перестанет быть схемой базы)

 

[Redjik]

Вурдалак, hell0w0rd, ребята а в доктрине можно сделать схему не от базы данных, а от адаптера?
Ситуация - есть база - в плохом состоянии, ненормализованная.
Трогать базу и глобально рефакторить - сейчас не вариант, решили прикрутить доктрину и потихоньку приводить в порядок.

Хочется так сделать:
1) Генерим актуальную схему по базе.
2) Декорируем или кидаем в адаптер - на выходу получаем схему с отрефакторенной структурой (которая будет в будущем).
3) Мапаем эту схему на модель.

На запись будет гемор, но пока нужно только чтение, когда понадобится запись, тогда уже нормализуем саму базу и выкинем этот адаптер.

Пример:
Есть таблица - вопросы, в этой таблице - колонка валидация (в ней хранится отсериализованный массив).
Хочется работать с этим массиовм как с коллекцией Моделек (которые в будущем будут в таблице question_validation) и будте браться по eager loading.

ЗЫ. решил бы через mysql view, но сериализованный масив =(

 

[WMix]

Схему можно сделать на основании массива. Откуда этот массив не имеет значения

 

[hell0w0rd]

Redjik,
1) doctrine:mapping:import
2) Ну какая бы каша не была в базе у тебя есть класс, можешь какой угодно интерфейс создать. На крайний случай raw запросы с ResultSetMapping.

Ну а с примером все же просто)
либо

public function getValidationConstraints()
{
    foreach($this->validationConstraints as $rawData) {
        yield new ValidationConstraint($rawData);
    }
}

либо

/**
* @ORM\PostLoad()
*/
public function onLoadNormalize(){}

 

[grigori]

от моделей к базе - это django, в yii - от базы к моделям через миграции

Redjik, адаптер ручками лень писать? в такой ситуации доктрина будет как корове седло, аккуратно внедрять кастомный orm лучше

 

[Redjik]

дак кастомный ORM дорого писать =)
а выбор только Doctrine или Propel ибо пляшем от legacy к symfony =))

 

[grigori]

Redjik, тогда не забудь подвесить вызовы колбеков для будущей гибкости, и обязательно их используй, да, и трейтов несколько штук

 

[Redjik]

и фасадов вбросить!

 

[grigori]

нене, фасады - старье, их пенсионеры пишут, тут же not only sql, надо пользоваться современными технологиями - к модели трейтом вешаешь кодировщик-декодер, который отрабатывает при загрузке/сохранении, а если какой-то старпер не оценит nosql и начнет нормализовывать - пусть пишет новый кодек

 

[keltanas]

Redjik, доктрина в принципе работает со схемой из конфига. Сгенерить конфиг на основе имеющихся таблиц тоже можно, но если структура таблиц не удовлетворяет допущениям, принятым в доктрине, что может что-то заработать не так. Поэтому придется сгенеренную схему править ручками и маппить обратно на базу, приводя структуру таблиц в доктрина-френдли состояние. Можно сгенерить миграцию и потом подправлять ее ручками до нужной кондиции.
Я так пару проектов мигрировал. Один с yii, который начинали писать жители земель, пролегающих чуть северо-западнее Крыма - там был в таблицах тихий ужас. Другой с самописной ORM, там попроще все вышло.
Сложность такой задачи будет зависеть от запущенности текущей схемы. Но, если структура бд не будет соответствовать конфигу доктрины, может и не работать. Поэтому придется лечить таблицы.

magnuz, когда я тут задавал подобный вопрос, меня чуть не сожгли на костре. Т.к. "работа от конфига" является для yii чем-то вроде религиозного экстремизма, и фанатики яро его отторгают.
Более-менее адекватную основу для сравнения своего конфига с базой можно найти здесь. Можно написать некую консольную команду, которая будет парсить твой конфиг, сверять по представленному по ссылке способу со структурой таблиц и генерить запросы для миграции.

 

[AmdY]

Говорят, царь — ненастоящий!

Вот так и живём, городим зачем-то DBAL, размышляем о Data mapping, а в реальности как только отошли от прямого мэпинга в стиле AR так сразу проблемы. Может и на ORM забить, набросать парочку простых запросов в стиле INSERT SELECT, которые шустро набросают данные в новую БД.

 

[grigori]

сгенеренную схему править ручками и маппить обратно на базу, приводя структуру таблиц в доктрина-френдли состояние. Можно сгенерить миграцию и потом подправлять ее ручками до нужной кондиции.

https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования)
https://ru.wikipedia.org/wiki/Фасад_(шаблон_проектирования)

жители земель, пролегающих чуть северо-западнее Крыма

и что, сайт таки работал? или у вас есть что-то сказать об Одессе?

magnuz, когда я тут задавал подобный вопрос, меня чуть не сожгли на костре. Т.к. "работа от конфига" является для yii чем-то вроде религиозного экстремизма, и фанатики яро его отторгают.
Более-менее адекватную основу для сравнения своего конфига с базой можно найти здесь. Можно написать некую консольную команду, которая будет парсить твой конфиг, сверять по представленному по ссылке способу со структурой таблиц и генерить запросы для миграции.

все проще. мы с samdark это обсуждали много лет назад, фича что-то делать с базой из моделей или через gui-интерфейс и одновременно делать модели была бы полезна, но всем влом