Всем привет. Работаю с фреймворком GORM. Может посоветуйте в какую

сторону копать: есть AutoMigrate. Можно ли сделать консольную команду, как в Django (python manage.py migrate), чтобы применить миграции?

2) Как мне получить файлы миграции? Как в Django (python manage.py makemigrations)

можно не использовать AutoMigrate, а мигрировать любой сторонней либой. Так и по идее и должно быть с GORM, когда проект выходит за стадию pet project

А что можете посоветовать? Я недавно в Go-тусовке.

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

Без разницы. Например rubenv/sql-migrate

не очень понял ваше сообщение

goose

Не понял если честно. Горм на 100% предсказуем как query builder. Если выключить автомиграции, то запросы строятся абсолютно такие же.

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

"Не может в частичный индекс" - речь о формировании "сreate index ... where"? Ну да, и ещё много чего - изменять данные, например. Разве я не предложил при выходе на прод отключить авто миграции парой сообщений выше?

дадада это я в документации видел, как ни пытался - у меня не получилось это сделать, я где-то помоему находил примеры, они работали, мой кейс - ни в какую, сейчас затрудняюсь вспомнить от своего кейса решение, помню только условие: есть таблица1-оружие, есть таблица2-игрок, игрок может иметь [0...N] разного оружия, но активным может быть только [0..1] оружия. Решение на уровне БД - через частичный индекс, а в GORM это сделать у меня не получилось

Функционал автомиграции горм очень ограничен и нужен чтобы быстро на коленке создать простые таблицы сущностей и связей. При появлении ограничений с этими миграциями план прост: - добавляете нормальную либу миграций, которая работает с произвольным sql. - дропаете локальную бд (где горм нагенерил таблицы) - запускаете программу с AutoMigrate = true в последний раз. Горм выводит все запросы на экран. - запросы, которые вывел горм, копируете и помещаете в в первый файл миграции другой библиотеки - дропаете бд ещё раз. - накатываете миграции новой либой - проверяете, что все работает Все это на каком-нибудь деве, естественно

можно и просто воспользоваться jetbrains бродилкой по базе и вызвать у таблицы generate ddl to query console

я рассуждал так: на GORM есть жалобы что он "иногда не может составить оптимизированный запрос". Соответственно, чтобы составлять запросы - необходимо обладать базой знаний по структуре рабочей БД, а раз он не может в частичный индекс - значит он не может и обладать и знаниями по нему, а значит какие-то запросы с его использованием он составит не самым оптимальным образом.

Что за бродилка?

это не про миграции, для миграций есть соответствующие инструменты

например она встроена в голэнд, но если у тебя на него аллергия - можно использовать datagrip

@Elmanov_anton описал, как можно изначальный sql файл собрать с горма)