Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 14

Есть такая штука 
 <source>
Используйте её пожалуйста, пощадите читателя.
Комментарий пока не оценивали0

В качестве альтернативного решения вместо ORM также можно использовать простой генератор SQL (например, squirrel). Он неплохо показывает себя показывает в связке со встроенным пакетом database/sql и sqlx.

Всего голосов 2: ↑2 и ↓0+2
Не рекомендую `GORM` и подобные ему ORM. Закопаетесь в изучении нюансов маппинга их конструкций на нативный SQL, вместо того, чтобы писать SQL напрямую. Мне лично очень нравится `reform`, писал на нём три проекта, остался доволен.
Всего голосов 4: ↑4 и ↓0+4

Согласен. Мы к этому и пришли. По возможности не использовать ORM на основе рефлексии, только кодогенерация на данный момент.

Комментарий пока не оценивали0

Кодогенерация чего, маппинга?

Комментарий пока не оценивали0

Да мапинг идля простых запросов.

Комментарий пока не оценивали0
Когда был в Lazada, то мы писали очень шустрое решение без кодогенерации — github.com/lazada/sqle. Посмотрите, может и вам подойдёт.
Всего голосов 1: ↑1 и ↓0+1
Для меня как-то сухая статья.
Не понятно почему сделали выбор с торону этих ORM!?

Можно было бы привести примеры работы с разными ORM ^(
Всего голосов 1: ↑1 и ↓0+1
В сторону этих ORM выбор был сделан из-за безопасности типов. В строго типизированном языке принимать на вход, например, в метод Save(value interface{}) пустой интерфейс опасно, можно легко ошибиться. Когда можно использовать кодогенерацию со строгой типизацией. В поиске примеров select запросов лучше всего посмотреть репозиторий orm-bench
Всего голосов 2: ↑2 и ↓0+2

А можно указать какие ORM паттерны эти библиотеки реализуют? Особенно интересно какие из них реализуют DataMapper.

Всего голосов 1: ↑1 и ↓0+1
Чего хотелось бы от orm

1) работа с переводимыми полями.
Конечно, переводимые поля это всего лишь еще одна связанная таблица. Но, согласитесь, что если в orm есть встроенная поддержка translatable это сразу в два раза упрощает работу с данными (например как в php doctrine)

2) автогенерация миграций
Многие базы данных поддерживают, но не всегда это равноценный функционал. Поэтому часто встречаю утверждения что в ткакой-то orm «тоже есть миграции»
Пока что я нашел только две orm c максимальной поддержкой миграций — php doctrine и javascript/typescript typeorm
Под максимальной поддержкой миграций я подразумеваю
1) автогенерацию кода на языке программирования orm (не sql-скрипты а например php-скрипты)
2) автогенерацию на основании сравнения текущей реальной базы данных с моделью (а не со схемой состояния которая была сгенерирована при прошлой миграции)
3) возможность кастомизировать полученные автогерерируемые скрипты

Интересно было бы услышать как Вы работали с переводимыми полями и миграциями. Ну а что касается конкретно go тут еще добавляется известная проблема с nullable полями

Действительно это интересный у Вас опыт но самые интересующие разработчиков вопросы пока что не нашли своего долдного освещения. А было бы очень интересно.
Всего голосов 1: ↑1 и ↓0+1

Для переводимых слов обычно используем отдельную сущность — словарь. Для миграций — пакет golang-migrate. А с nullable полями всегда непросто, это решается на уровне работы по валидации данных

Всего голосов 2: ↑2 и ↓0+2
Вот об этом я и говорю…
Тема не была раскрыта полностью. Много вопросов которые можно было избежать если бы пересичленные ORM были приведены в более детальном сравнении с примерами кода их использования. А не объяснять потом в комментариях…
Всего голосов 2: ↑2 и ↓0+2

Спасибо за рекомендации. Наш доклад на Hot Backend был направлен в первую очередь на знакомство с языком Go, на детальные вопросы мы отвечали после доклада. Будем иметь в виду для следующих публикаций)

Всего голосов 3: ↑3 и ↓0+3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr