Почему gorm не любят ?

типа не go way. сырой sql считается более конвенциональным

Потому что orm это зло. Часто генерит не очень очевидные запросы. А билдеры что называется straightforward way

И отсутствие типизации заодно 🫠 Хотя с этим в целом ничего не сделать

да я бы не сказал что прям зло. есть случаи когда лучше орм

Если дело доходит до высокооптимального запроса, когда знаешь как работает планировщик, то orm превращается в костыль. И любой способ заставить сгенерить правильный запрос превращается в пытку.

бтв это работает только если ты чемпион по sql. если нет то вполне бывает что нагенереные запросы быстрей

А это ещё хуже - не знать что генерит orm и почему )

да хз. не знать что-то это не грех как по мне, у всех нас есть пробелы в знаниях так или иначе. и если понимаешь что не вывозишь, то переложить на инструмент часть гемора это не страшно.

Ну я же говорю типа зависит от критериев. Если мы говорим про разработку highitensive системы, то и человек там будет соответствующий все поднимать. А если фичи пилить и скорость доставки важнее, то да, orm спасет, но до по ры до времени, пока не прилетит нагрузка, а там голые запросы и ничего больше

да, но если интерфейсы между use кейсами и гейтвеями нормально написаны, то можно без титанических усилий поменять когда нагрузка появится

я не знаю кто не любит gorm. не любить инструмент, который может сэкономить время и повысить читаемость кода (после 30 минут изучения документации), как минимум, странно. основная проблема, в которую упирается любой орм - производительность. вторая явная проблема "машинные" запросы. зачастую бывает проще и быстрее собрать запрос руками. всё зависит от того, чем ваше приложение будет заниматься. если говорить о проблемах, которые специфичны для типизированного языка как go, то это рефлексия и избыточность. обычно, когда работаешь с орм, не очень хочется напрягаться и задумываться о накладных расходах. мы делает select, выбирая два поля, а в модель засовываем структуру, мапу или слайс из 10 полей. и всё это там путешествует под капотом. потом это приходится утилизировать gc, на всё на это тратится память и процессорное время в общем, gorm это прекрасный инструмент. но нужно понимать его лимиты

Смотри вот простой кейс который не покрывается в gorm. Insert into on conflict с cte join на returning. Это вообще невозможно написать в нем

да я ж не спорю. но когда появится в этом потребность можно поменять если архитектура изначально продумана

Стикер

Думаю будет проще показать ) сек

главное вслух не читать, чтобы не вызвать диавола, да?))

The currently accepted answer seems ok for a single conflict target, few conflicts, small tuples and no triggers. It avoids concurrency issue 1 (see below) with brute force. The simple solution has its appeal, the side effects may be less important. For all other cases, though, do not update identical rows without need. Even if you see no difference on the surface, there are various side effects: It might fire triggers that should not be fired. It write-locks "innocent" rows, possibly incurring costs for concurrent transactions. It might make the row seem new, though it's old (transaction timestamp). Most importantly, with PostgreSQL's MVCC model UPDATE writes a new row version for every target row, no matter whether the row data changed. This incurs a performance penalty for the UPSERT itself, table bloat, index bloat, performance penalty for subsequent operations on the table, VACUUM cost. A minor effect for few duplicates, but massive for mostly dupes. Plus, sometimes it is not practical or even possible to use ON CONFLICT DO UPDATE. The manual: For ON CONFLICT DO UPDATE, a conflict_target must be provided. A single "conflict target" is not possible if multiple indexes / constraints are involved. But here is a related solution for multiple partial indexes: UPSERT based on UNIQUE constraint with NULL values Back on the topic, you can achieve (almost) the same without empty updates and side effects. Some of the following solutions also work with ON CONFLICT DO NOTHING (no "conflict target"), to catch all possible conflicts that might arise - which may or may not be desirable. Without concurrent write load WITH input_rows(usr, contact, name) AS ( VALUES (text 'foo1', text 'bar1', text 'bob1') -- type casts in first row , ('foo2', 'bar2', 'bob2') -- more? ) , ins AS ( INSERT INTO chats (usr, contact, name) SELECT * FROM input_rows ON CONFLICT (usr, contact) DO NOTHING RETURNING id --, usr, contact -- return more columns? ) SELECT 'i' AS source -- 'i' for 'inserted' , id --, usr, contact -- return more columns? FROM ins UNION ALL SELECT 's' AS source -- 's' for 'selected' , c.id --, usr, contact -- return more columns? FROM input_rows JOIN chats c USING (usr, contact);

Я не знаю ни одной orm, которая нормально умеет работать с нестандартными запросами. Для этого любая orm умеет в raw query

Это вполне стандартный запрос для postgres и oracle

Да, я кстати видел прожект который из gorm после всех оптимизаций остался только вызов Exec. И самое фиговое, что некоторые разрабы, наивно верили, что всё-таки ормка должна поддерживать все что нужно, и пытались оставить всеми силами возможность ее использования. Даже когда очевидно, что она не подходит. Т.е. это вторая сторона медали, когда есть неуверенность и элементы карго-культа, что боги написали орм и там все оптимально работает.

честно сказать, не вижу большой проблемы держать инстанс для gorm'а

когда в руках молоток все кажется гвоздем)

Ну там смысл был в том, что пока он в проекте, всегда есть искушение отрефакторить, чтобы все выглядело нативно для орм. Но это искушение дьявола ) вот выше кстати экспириенс из других орм отметили )

А я видел ваз-2106 на треке, туда эта хреновина доехала самостоятельно, а вот обратно уже на эвакуаторе🤷‍♂️ Инструмент нужно подбирать под задачу

Не, это не так работает. Сперва пилится MVP и это на момент рождения проекта уже Легаси, которое в итоге будет переписано. Может тогда не надо орм ?

Ты не поверишь, но это обычная эволюция проекта на любом языке с любой orm, уже много лет

Ну так, в том и смысл выкинуть промежуточное звено эволюции и писать чистые запросы

Большая часть кода в mvp это будущее легаси. Может из-за этого перестать делать mvp и в целом не создавать новые бизнесы?

Смысл mvp в том, что бы максимально быстро создать продукт, выкинуть его на рынок и начать операционную деятельность. Если orm позволяет на этом этапе сэкономить время - глупо от неё отказываться

Это не аргумент, скорость запуска орм, никак не прямо не коррелирует со скорость деливери продукта

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

Напоминает анекдот про кредиты и нового русского мне. Цель MVP — сделать работоспособный продукт, который можно поддерживать. Если ваш продукт поддерживать невозможно, то вы выдаёте POC за MVP

https://habr.com/ru/companies/lingualeo/articles/515530/ )))))))) TLDR: парни повыгоняли поганой метлой PHP разрабов, которые не правильно делали-готовили запросов, перевели все на хранимки и у них скорость поправилась. БД, как водиться, ботлнек при хреновой архитектуре и отсутсвии нормальной структуры, запросов и даже индексов. От этого у хаброжителей и любителей ORM сгорела жепа)

Уже давно так делаю и другим рекомендую. Область применимости orm очень узкая. Это та же история, что из высокоуровневыми фреймфорками - все эти типовые "уже написанные" паттерны быстро дают первые результаты на старте, но потом скорость реализации фич начинает падать из-за того-что тривиальная задача превращается в борьбу с рамками выставленными orm/фрэймворком.

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

это статья для маркетинга ) на самом деле там кухня очень-очень адская была внутри ) со срывами сроков, нервами, багами и прочим )

Если ваш продукт невозможно поддерживать из-за orm, то скорее всего проблема не в orm)

Ну мораль басни не в хранимках, а в том, что надо нормально запросы писать и хоть иногда планировщик запроса запускать, не говоря уж про индексы (про селективность также не забываем и не переусердствуем) Такто можно большинство бэкэндеров на мороз и вструмить hasura, если у вас там сплошные CRUD запросики)

При чём тут ORM? Мы же тут горм обслуждаем, правда?

там нормально было написано ))

С чего вдруг хранимки сложно тестировать?

Я вот ещё ни разу не видел проекта, который бы целиком ложился на crud. Всякие специфичные требования и соответственно операции есть чуть менее чем всегда

Мне казалось что мы тут обсуждаем orm в целом, в существовании gorm лично я никакого смысла не вижу

Обсуждение было вокруг gorm. Тезис в том, что он кривой из коробки как орм в целом.

Всем известно издавна, он был сделан из говна (с) Что тут обсуждать то?

Ну меня всегда триггерит какое-то эфемерное ускорение деливери

Потому же почему не любят ORM в других языках)

потому что он слабенький. В каждом orm есть первая космическая скорость - когда удобней просто руками написать запрос, чем возиться с билдером. И вот в горме она очень маленькая.

Это вторая космическая. Первая космическая — взять нормальный билдер

каждый раз когда я вижу вопрос в духе: я тут написал db.Where("amount > (?)", db.Table("orders").Select("AVG(amount)")).Find(&orders) а оно почему-то не работает. Чтобы разобраться нужно держать в голове поля модели, тэги, поля в базе, и последовательность операций в ОРМ. Как разработчик и руководитель небольшой команды, я думаю это трата времени и денег. Прочитать SQL запрос не сложно, если хочется удобств, есть sqlx и squirell, где можно сдампить sql и понять что происходит. С Гормом это сложнее, ну или это сложнее для меня

а gorm кстати не имеет метода типа ToSQL?

кстати, имеет https://gorm.io/docs/sql_builder.html#ToSQL. Но непонятно, в какой момент придется его использовать

Имеет режим debug

потому-что оно абстрагирует важные детали имплементации

хибернейт или алхимия или там активрекорд тоже абстрагируют важные детали имплементации, но их любят

Просто как я понимаю, это в го сообщество такое отношение к орм, в питоне например уважают и поклоняются орм, поэтому я сразу подумал что дело в самом gorm, а не в орм в целом, так значит gorm хорош или нет?

Gorm должен попробовать каждый разработчик, который приходит в go из других языков. Попробовать и понять, что лучшей orm для go еще не изобрели