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

[StalkerClasses]

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

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

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

GitHub - Insolita/yii2-migrik: Yii2 Gii-tools for create migration files

Yii2 Gii-tools for create migration files. Contribute to Insolita/yii2-migrik development by creating an account on GitHub.

github.com

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

 

[WMix]

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

 

[StalkerClasses]

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

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

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

 

[StalkerClasses]

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

 

[StalkerClasses]

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

Посмотрев Propel насколько понимаю он дает возможность подсветки синтаксиса в IDE при создании запросов применительно к названиям колонок и таблиц в БД

 

[WMix]

Посмотрев Propel насколько понимаю он дает возможность подсветки синтаксиса в IDE при создании запросов применительно к названиям колонок и таблиц в БД

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

По идее любая ORM должна давать полную абстрацию от БД.

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

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

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

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

 

[WMix]

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

 

[WMix]

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

 

[StalkerClasses]

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

Абсолютно не понимаю какую проблему решают миграции?

Я создаю модель:

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]

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

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

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

 

[WMix]

Сохранить копию БД и все.

это сложный откат, да, лучше копия, чем без, но еще проще rollback

 

[WMix]

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

 

[Valick]

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

 

[StalkerClasses]

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

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

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

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

 

[StalkerClasses]

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

/**
* @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{

Чем такой подход хуже миграций?