Комментарии 14
Есть такая штука
<source> 
Не рекомендую `GORM` и подобные ему ORM. Закопаетесь в изучении нюансов маппинга их конструкций на нативный SQL, вместо того, чтобы писать SQL напрямую. Мне лично очень нравится `reform`, писал на нём три проекта, остался доволен.
Когда был в Lazada, то мы писали очень шустрое решение без кодогенерации — github.com/lazada/sqle. Посмотрите, может и вам подойдёт.
Для меня как-то сухая статья.
Не понятно почему сделали выбор с торону этих ORM!?
Можно было бы привести примеры работы с разными ORM ^(
Не понятно почему сделали выбор с торону этих ORM!?
Можно было бы привести примеры работы с разными ORM ^(
В сторону этих ORM выбор был сделан из-за безопасности типов. В строго типизированном языке принимать на вход, например, в метод Save(value interface{}) пустой интерфейс опасно, можно легко ошибиться. Когда можно использовать кодогенерацию со строгой типизацией. В поиске примеров select запросов лучше всего посмотреть репозиторий orm-bench
А можно указать какие ORM паттерны эти библиотеки реализуют? Особенно интересно какие из них реализуют DataMapper.
Чего хотелось бы от orm
1) работа с переводимыми полями.
Конечно, переводимые поля это всего лишь еще одна связанная таблица. Но, согласитесь, что если в orm есть встроенная поддержка translatable это сразу в два раза упрощает работу с данными (например как в php doctrine)
2) автогенерация миграций
Многие базы данных поддерживают, но не всегда это равноценный функционал. Поэтому часто встречаю утверждения что в ткакой-то orm «тоже есть миграции»
Пока что я нашел только две orm c максимальной поддержкой миграций — php doctrine и javascript/typescript typeorm
Под максимальной поддержкой миграций я подразумеваю
1) автогенерацию кода на языке программирования orm (не sql-скрипты а например php-скрипты)
2) автогенерацию на основании сравнения текущей реальной базы данных с моделью (а не со схемой состояния которая была сгенерирована при прошлой миграции)
3) возможность кастомизировать полученные автогерерируемые скрипты
Интересно было бы услышать как Вы работали с переводимыми полями и миграциями. Ну а что касается конкретно go тут еще добавляется известная проблема с nullable полями
Действительно это интересный у Вас опыт но самые интересующие разработчиков вопросы пока что не нашли своего долдного освещения. А было бы очень интересно.
1) работа с переводимыми полями.
Конечно, переводимые поля это всего лишь еще одна связанная таблица. Но, согласитесь, что если в orm есть встроенная поддержка translatable это сразу в два раза упрощает работу с данными (например как в php doctrine)
2) автогенерация миграций
Многие базы данных поддерживают, но не всегда это равноценный функционал. Поэтому часто встречаю утверждения что в ткакой-то orm «тоже есть миграции»
Пока что я нашел только две orm c максимальной поддержкой миграций — php doctrine и javascript/typescript typeorm
Под максимальной поддержкой миграций я подразумеваю
1) автогенерацию кода на языке программирования orm (не sql-скрипты а например php-скрипты)
2) автогенерацию на основании сравнения текущей реальной базы данных с моделью (а не со схемой состояния которая была сгенерирована при прошлой миграции)
3) возможность кастомизировать полученные автогерерируемые скрипты
Интересно было бы услышать как Вы работали с переводимыми полями и миграциями. Ну а что касается конкретно go тут еще добавляется известная проблема с nullable полями
Действительно это интересный у Вас опыт но самые интересующие разработчиков вопросы пока что не нашли своего долдного освещения. А было бы очень интересно.
Для переводимых слов обычно используем отдельную сущность — словарь. Для миграций — пакет golang-migrate. А с nullable полями всегда непросто, это решается на уровне работы по валидации данных
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Язык Go: выбор ORM