Комментарии 6
НЕ
ИСПОЛЬЗОВАТЬ
GORM
(как и любые другие магические концепции, польза от применения которых сомнительна а вред явно ощутим)
Gorm имеет достаточно большое сообщество, эта статья написана что бы помочь разработчиками, которые работают с Gorm и столкнулись с той же проблемой, что и мы.
Я просто делюсь готовым решением, в надежде что это кому то поможет)
а тем более для таких сложных типов как geometry и geography
GORM будет просто вызывать методы Scan и Value, которые описаны в стандартной библиотеке database/sql. Не какой магии в чтении и записи нет, поэтому и проблем быть не может.
В случае более сложных запросов, например, когда Вам нужно найти полигоны в которые входит точка как в примере в статье, можно считать что GORM выполняет роль SQL билдера, в этом тоже я думаю ничего магического нет.
Я пишу на Питоне, но немного знаком с Go. Часто встречаю подобную точку зрения «В Go ORM не нужен». Но не встречал подробного разбора, почему. Можете объяснить почему?
Есть две с половиной основные причины:
Производительность - в го совершенно невозможно сделать производительную ORM - в языке нет comptime, нет аннотаций, нет ничего из того, что нужно чтобы ORM производила все расчёты при компиляции, или хотя бы на старте приложения и не грузила рантайм.
Магия - в го у нас принято, что явное лучше неявного. Сама идея ORM - добавить магии, "ты просто пишешь некую entity, а дальше всё само". Этот подход может быть не так плох для проектов, которые не требуют оптимизации, но это противоречит явности, плюс исторически сложилось, что го берут как раз там, где другие простые языки показали себя медленными и требуется увеличение скорости.
Резюмируя - вы нарушаете один из основных принципов и теряете в производительности, ради сомнительных преимуществ.
Лично я например слабо понимаю чем условное
db.Find(&entities).Error
лучше чем
db.Query("select * from entities", &entities)
Как подружить Gorm и PostGIS, решение промышленного уровня