а не создавать пустые файлики)

этот умел на основании моделей и бд генерить миграции

лол

показать?

я знаю, что если создавать все модели через команд лайн, то он создаст и миграции

но потом ты поменяешь поле в модели, и кли тебе уже не поможет)

чувак

но потом ты поменяешь поле в модели, и кли тебе уже не поможет)

а как оно должно помочь?

а эта тулза делала дифф

реверс инжиниринг, вся ботва

а эта тулза делала дифф

я думаю не просто так загнулась видимо не нужно было это всё

лол

чувак написал, что у него нет времени поддерживать проект

но штука суперская

чувак написал, что у него нет времени поддерживать проект

так опенсорс, чего сообщество не продолжает?

хз, нравится руками миграции писать, видимо)

я не пишу руками

было бы у меня мозгов чуть побольше и времени - может и взялся бы)

генерирую из кли

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

а ничего что так не делается?

Не делаю миграции и норм живу

уже не говоря о том, что создавать модели в консоли - то еще развлечение)

кровавый ентерпрайз же

если я хочу поменять модель, первое что я делаю, это думаю, и планирую, затем генерирую миграцию, и уже потом обновляю модель

кстати

для справки

я думал кровавый и нода вещи не очень совместимые :)

миграции это не только изменение столбцов

а ещё МИГРАЦИЯ данных!

это ни одна утилита сделать не сможет

я про то, что две операции вместо одной

и миграция ДАННЫХ - это сиды)

и миграция ДАННЫХ - это сиды)

че?

принято разделять эти вещи обычно

Эээ, чо

меняешь структуру таблиц - делаешь миграцию, меняешь содержимое - делаешь сиды

меняешь структуру таблиц - делаешь миграцию, меняешь содержимое - делаешь сиды

чувак ты кое-чего не знаешь))

У тебя была колонка name, ты решил разнести на first_name и last_name, а в продакшне уже тыща юзеров

я очень много чего не знаю)

Ммм... Сиды - это тестовые данные, как бэ)

я очень много чего не знаю)

сиды это вообще другое

И в миграции ты это пишешь как раз

Ммм... Сиды - это тестовые данные, как бэ)

вот!

я очень много чего не знаю)

все делается в миграциях как раз данные изменяются в миграциях

У тебя была колонка name, ты решил разнести на first_name и last_name, а в продакшне уже тыща юзеров

это запросом разрулить можно, в скл есть конкат (или что-то подобное)

не конкат, наоборот в смысле)

Ага, збс, а ты в продакшн будешь идти и руками делать запрос?

в миграции же - данные остались те же, только структура поменялась

Миграция - это DSL для описания подмножества условно-обратимых запросов к базе

Условно - потому что часть данных будет теряться при откате. Но схема теряться не будет

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

Имхо, по-хорошему миграции должны быть проверены 2+ людьми

ну, смотря какие - если пример выше, то задача тривиальная

если комплексная, то конечно

Практика показывает, что лучше и тривиальные вещи перепроверять

https://vc.ru/n/renova-fail

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

++

для этого есть дев серваки, чтоб излишне не параноить)

ну и тесты можно накидать а-ля "интеграционные", если дикие изменения

так все и делают

если не написал сам миграцию, то можешь проглядеть что там нагенерила программка

проглядеть можешь даже если сам написал

проглядеть можешь даже если сам написал

Поэтому лучше все перепроверять И не только самим И по отдельности, а потом все вместе обсудить

проглядеть можешь даже если сам написал

вероятность намного ниже

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

ERROR: S client not available

только вот любая миграция — дело ответственное и бездумное переименование/добавление полей это уже проблема

по мне написание миграции должно быть первым

бизнес-требования меняются часто, тут бездумность не причем

бизнес-требования не обязывают тебя писать миграцию после изменения кода модели

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

отсюда все проблемы и тормоза обычно

наоборот)

надумают себе охуенных абстракций, а потом думают как эффективно это хранить в базе и как оптимизировать выборки

у нас чувак пару месяцев проектировал бд, потом требования координально поменялись)

проблема тех кто требует

проблема тех кто требует

кек, ваши бизнес-задачи не подходят под мои офигенные схемы

надумают себе охуенных абстракций, а потом думают как эффективно это хранить в базе и как оптимизировать выборки

а в чем проблема?

а в чем проблема?

В тормозах

бизнес-требования меняются часто, тут бездумность не причем

Тут уж у кого как Условия в лице бизнеса в нашем разговоре до этого не стояло и намека на него не было

кек, ваши бизнес-задачи не подходят под мои офигенные схемы

Когда требования кардинально меняются я тут же увольняюсь

В тормозах

нет никаких тормозов

они всегда меняются

Когда требования кардинально меняются я тут же увольняюсь

окей, тут у нас явно есть непонимание, что такое "кардинально"?

нет никаких тормозов

На си пишешь?

На си пишешь?

не, на всяких скриптовых этих вот языках

не, на всяких скриптовых этих вот языках

Ты же согласен, что один сложный запрос на SQL будет быстрее аналогичного решения на множестве примитивных SQL запросов и обработки данных на стороне приложения?

ну это уже не та степь

Ты же согласен, что один сложный запрос на SQL будет быстрее аналогичного решения на множестве примитивных SQL запросов и обработки данных на стороне приложения?

ну время на отправку запроса и все такое, вполне вероятно да

ну время на отправку запроса и все такое, вполне вероятно да

И на собственно исполнение

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

И на собственно исполнение

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

Говоря проще, исполнение, да

поэтому это время будет грубо говоря похожим

в любом случае больше всего будет потрачено времени на io

если остальное время одинаковое *

ну, если массовое изменение большого объема данных, то может и нет)

но это довольно редкие случаи