Жить без миграций Laravel // Yii2

StalkerClasses

Новичок
Есть ли инструменты которые позволяют обходится без миграций применительно к yii2 или laravel.

Например описание структуры таблицы в молел. Какие есть минусы у этого?

Первое что нашёл

Есть ли что то ещё подобное?
 

WMix

герр M:)ller
Партнер клуба
возьми Propel он тоже все сгенерит. не уверен что тебе это поможет, в том смысле что и с программой чтото делать нужно, и хорошо было бы, чтоб изменения базы было согласованно, с изменением программы, ну те проблема не в миграции, а во всей логике
 

StalkerClasses

Новичок
возьми Propel он тоже все сгенерит. не уверен что тебе это поможет, в том смысле что и с программой чтото делать нужно, и хорошо было бы, чтоб изменения базы было согласованно, с изменением программы, ну те проблема не в миграции, а во всей логике
Поработав с миграциями - совсем не понимаю зачем они в принипе нужны?
В той же модели Yii2 можно было бы прописывать публичные свойства с указанием их типов через аннотации.
И отслеживать изменения через тот же git гораздо удобнее?

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

StalkerClasses

Новичок
По идее любая ORM должна давать полную абстрацию от БД.
По факту меняя название какой-нибудь колонки уже тяжелова-то найти все колонки по коду через IDE. И тотже IDE не подсвечивает MySQL-колонки и названия таблиц когда работаешь и собираешь запрос через конструктор...
 

StalkerClasses

Новичок
возьми Propel он тоже все сгенерит. не уверен что тебе это поможет, в том смысле что и с программой чтото делать нужно, и хорошо было бы, чтоб изменения базы было согласованно, с изменением программы, ну те проблема не в миграции, а во всей логике
Посмотрев Propel насколько понимаю он дает возможность подсветки синтаксиса в IDE при создании запросов применительно к названиям колонок и таблиц в БД
 

WMix

герр M:)ller
Партнер клуба
Посмотрев Propel насколько понимаю он дает возможность подсветки синтаксиса в IDE при создании запросов применительно к названиям колонок и таблиц в БД
ты смотришь orm я про миграцию.

По идее любая ORM должна давать полную абстрацию от БД.
я не понимаю слово "полная", база это о хранении, программа о изменении
ORM это про mapping отношений, миграция это про изменение, добавлении удалении полей. замены структуры.

после изменении програмного кода, всегда можно запустить герерацию миграционного скрипта, но не всегда это удобно, если только ты просто не меняешь названия полей.
миграция это целый комплекс мер, по переводу хранилища,

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

а как на счет отката?
неужели ты просто грохнешь таблицу (не пререименуешь на всякий)
 

WMix

герр M:)ller
Партнер клуба
ну и последнее, далеко не всегда, сущностью является табличка (вернее строка) возможно только в твоей аппликации
 

WMix

герр M:)ller
Партнер клуба
ты ищешь проблему не там. нет проблемы писать программу, это всегда разный подход. не пытайся запрограммировать процесс программирования таких программ много, все узкобокие и никому не нужные.
проблема только в том что писать, какой подход применить в том или ином случае чтоб крови меньше было и как поддерживать
 

StalkerClasses

Новичок
ты ищешь проблему не там. нет проблемы писать программу, это всегда разный подход. не пытайся запрограммировать процесс программирования таких программ много, все узкобокие и никому не нужные.
проблема только в том что писать, какой подход применить в том или ином случае чтоб крови меньше было и как поддерживать
Абсолютно не понимаю какую проблему решают миграции?

Я создаю модель:
PHP:
class user extends orm
{
    public id; // INT PK
    public propsys_del;
    public propchar_username;
    public proptext_html;
    public propmedia_pic;
    public propref_country;
}
Запускаю гит и все видят эти изменения и запускают скрипт обновления БД на основе этих переменных. А так ещё нужно описать и корректировать файл миграции.
 

StalkerClasses

Новичок
Получается конструктор запросов живет отдельной жизнью
Миграции отдельной жизнью
Модель тоже отдельной жизнью

И это постоянно нужно синхронизировать.
 

StalkerClasses

Новичок
По мимо миграций например сейчас перечитываю документацию по yii2, вот есть валилаторы проверки (типы), почему это нельзя было реализовать текущим интерфейсом? Приходится каждый раз вспоминать какие варианты можно забить в массив. IDE же это не подсвечивает никак.
 

StalkerClasses

Новичок
Забыл ещё сказать что форма редактирования модели также живет отдельной жизнью.
 

StalkerClasses

Новичок
ты смотришь orm я про миграцию.


я не понимаю слово "полная", база это о хранении, программа о изменении
ORM это про mapping отношений, миграция это про изменение, добавлении удалении полей. замены структуры.

после изменении програмного кода, всегда можно запустить герерацию миграционного скрипта, но не всегда это удобно, если только ты просто не меняешь названия полей.
миграция это целый комплекс мер, по переводу хранилища,

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

а как на счет отката?
неужели ты просто грохнешь таблицу (не пререименуешь на всякий)
Почему не грохнуть? Смысл в Ее переименовании? Сохранить копию БД и все.
 

AmdY

Пью пиво
Команда форума
Миграции нужны для более сложных операций, особенно когда на проекте есть уже данные.
Вот допустим в твоём примере, тебе понадобилось вместо propchar_username использовать propchar_first_name? propchar_last_name. Поменял код, автоматический генератор дропнул старую колонку и добавил две новые, данные все будут утерены.
Затем на эти поля нужно добавить индекс по двум полям, да ещё полнотектовый со словорями и генератор зашёл в тупик.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Ребят, если человек с 2013 года тут сидит и не понял, нужны ли ему миграции или нет, а точнее понял, что нет - то имхо все ваши старания ему не воткнулись никуда

По идее любая ORM должна давать полную абстрацию от БД.
По факту меняя название какой-нибудь колонки уже тяжелова-то найти все колонки по коду через IDE. И тотже IDE не подсвечивает MySQL-колонки и названия таблиц когда работаешь и собираешь запрос через конструктор...
И правда, переименования в шторме, которыми все пользуются в ларке или симфони - придумал какой-то злой волшебник. И, да, если ты часто меняешь названия колонок - надо бы подумать о том, что у тебя в БЛ все херово с предварительным проектированием и описанием задач. И таки еще раз, да, IDE подсвечивает даже данные в QB
 

WMix

герр M:)ller
Партнер клуба
возможно у вас нет тестов и ты не понимаешь, как просто пишется код и напрягаешь свои мозги решая простые задачи, устал и ищешь отдушины. попробуй TDD по началу пишешь много, пока не опишешь основные кейсы, после перестанешь браузер открывать для проверки.
 

Valick

Новичок
StalkerClasses, ты принял для себя решение, что миграции придумали идиоты для идиотов, теперь ты хочешь в этом убедить участников форума?
Даже когда ты работаешь над проектом один, миграции это очень удобно. Не надо рассматривать миграцию атомарно, цепочка миграций может быть сколь угодно длинной. При необходимости эту цепочку всегда можно повторить один в один относительно любой точки.
 

StalkerClasses

Новичок
Мой вопрос лишь в том какую глобоид руб проблему решают миграцмм?

Убрал колонку, убрал модель - не обязательно удалять это физически в БД. Про переименования да согласен это проблема. И то думаю можно решить.

Можно ли генерировать миграцию с существующей БД создав там все необходимые таблицы и колонки?

Где это IDE делает подсветку значений которые можно передать в массив? Для того же Yii2?
 

StalkerClasses

Новичок
Самая актуальная база как правило все равно хранишься на продакшине.

PHP:
/**
* @property integer    $id         @column pk|comment("Id")
* @property string     $username   @column string(100)|unique|notNull|default("Vasya")
* @property string     $email      @column string(200)|unique()|defaultValue("[email protected]")
* @property string     $password   @column string(200)|notNull|expr(null)
* @property string     $created_at @column string(200)|notNull|expr('CURRENT_TIMESTAMP')
*/
class TestModel extends ActiveRecord{
Чем такой подход хуже миграций?
 
Сверху