Comments 7
Прошу не считать этот коментарий слишком токсичным (а он будет токсичным), но:
Каждый разработчик должен написать свой фреймворк, ровно как и то, что он должен его никому не показывать
Документации считаем что нет
Ровно как и юнит тестов
Контекста (
context.Context) тоже нет - только по этому критерию сразу мимо кассыАвтоматические миграции имеют свою цену, и платить ее придется (по закону Мерфи) вот ровно тогда, когда на это совсем не будет бюджета
Constrains, returning, etc...
Вы проделали классную исследовательскую работу, но собирать фидбэк таким образом - стоит ли?
разделить ответствености генерации миграций и прикладного кода
И чем описание миграций на "сыром" SQL в отдельной директории будет лучше описания ямлика и добавления большого количества тегов в структуры?
В процессе разработки на Go нередко встаёт вопрос о создании удобного уровня абстракции
Гораздо реже чем где-либо еще. Обмазываться абстракциями ради абстракций может и принято, например, в Java, но точно не в Go.
это CLI-инструмент, которая не нуждается в прямой интеграции в go.mod
Но потребует дополнительной установки бинарника в контейнеры.
SetMaxResults(10)
А чем вам слово LIMIT не угодило? ИМХО, когда разработчик использует query builder, то он интуитивно ищет методы, схожие по названию с операциями в SQL.
И так же я не понял, в чем смысл объединения генератора миграций и query builder.
YAML-файл
Спасибо, нет.
Начинать на таком одно удовольствие. Главное вовремя соскочить, чтобы развивать, тюнить и поддерживать - кто то другой был должен.
https://github.com/ManyakRus/crud_generator
у меня сделано наоборот:
делаешь таблицы в БД, а потом код на go сам сгенерируется :-)
Для Go есть прекрасные и проверенные sqlc и GORM. Что-то новое конечно же хорошо, понаблюдать можно
Удобная ORM для Go с генерацией миграций и Query Builder’ом: Gormite