The reason people use ORMs is because they don't want to write SQL. The reason people don't want to write SQL is because SQL is not portable with each database implements its own SQL variant/dialect. Switching databases often involves rewriting the SQL instructions. But ORM is an overengineered solution to this problem. It may be slow because the generated code may not be tailored to your specific scenario. Debugging can also be problematic since it is difficult to check and fix the underlying SQL instruction that is causing the problem. Long-term maintenance may also be difficult, such as database upgrade, migration, schema changes, etc. A thin wrapper over SQL language that is portable across databases is a better solution.
On Sunday, December 22, 2024 at 4:50:21 PM UTC+7 Brian Candler wrote: > > WHERE email = CASE WHEN sqlc.arg(email) = '' then NULL else > sqlc.arg(email) END > > What database is that? If it's Postgres then I believe that expression > collapses to > > WHERE email = NULLIF(sqlc.arg(email), '') > > But wouldn't it be better to pass null explicitly, rather than assume > "empty string means null"? sqlc allows this by using sqlc.narg() instead of > sqlc.arg(), see > https://docs.sqlc.dev/en/stable/reference/macros.html#sqlc-narg > > -- name: GetAuthor :one > SELECT * FROM authors > WHERE name = sqlc.narg(name) > OR bio = sqlc.narg(bio) > LIMIT 1; > > The parameter is then a sql.NullString > > type NullString struct { > String string > Valid bool // Valid is true if String is not NULL > } > > And/or look at the emit_pointers_for_null_types option in > https://docs.sqlc.dev/en/latest/reference/datatypes.html#text > > On Saturday, 21 December 2024 at 19:48:59 UTC Samir Faci wrote: > >> This might be a tangent from the thread, but while I really liked SQLC, I >> found that doing anything remotely dynamic became too cumbersome. I >> started out with SQLC and had SQLX as a fallback. >> >> As soon as you want to have optional filters you end up with a hideous >> query you have to contend with. >> >> For example: >> >> ```go >> -- name: ListAuthors :one >> SELECT * FROM authors >> WHERE email = CASE WHEN sqlc.arg(email) = '' then NULL else >> sqlc.arg(email) END >> OR username = CASE WHEN sqlc.arg(username) = '' then NULL else >> sqlc.arg(username) END >> LIMIT 1; >> ``` >> I mean sure that works but it just feels kind of gross. You can end up >> with all potential conditional having to be built into the query and case >> statements. Do people really use this pattern in prod? >> >> it feels like as soon as. you try to add dynamic queries SQLC appeal >> dwindles. That being said, for simple queries SQLC is awesome. <3 >> >> >> >> On Thu, Dec 19, 2024 at 9:17 AM Mike Schinkel <mi...@newclarity.net> >> wrote: >> >>> Hi Bhavesh, >>> >>> I am also not a fan of ORMs, but I am a big fan of sqlc so I will 2nd >>> Brian Candler's recommendation. >>> >>> Sqlc is one of the few Go packages/tools I consider a must-use for any >>> of my projects that need to interact with SQL databases. >>> >>> -Mike >>> >>> On Dec 19, 2024, at 8:23 AM, 'Brian Candler' via golang-nuts < >>> golan...@googlegroups.com> wrote: >>> >>> I am not a fan of ORMs. Application performance problems are usually >>> down to poorly formed SQL queries (and/or lack of supporting indexes), >>> which ORMs can mask or amplify. >>> >>> For an alternative approach, have a look at >>> https://github.com/sqlc-dev/sqlc >>> >>> In short, you write the set of SQL queries to meet your application's >>> needs, and then they get automatically wrapped in idiomatic Go. >>> >>> For joins, see: https://docs.sqlc.dev/en/stable/howto/embedding.html >>> >>> Refs: >>> https://conroy.org/introducing-sqlc >>> https://sqlc.dev/ >>> https://play.sqlc.dev/ >>> >>> https://alanilling.com/exiting-the-vietnam-of-programming-our-journey-in-dropping-the-orm-in-golang-3ce7dff24a0f >>> >>> On Thursday, 19 December 2024 at 13:01:25 UTC Bhavesh Kothari wrote: >>> >>>> I read few posts regarding ORMs in golang & realized, few peoples are >>>> not happy with it. >>>> >>>> They mentioned to use raw queries with our own wrapper if want to make >>>> few things reusable. >>>> >>>> I was actually using Gorm, which was super slow, then I started >>>> research regarding performance efficient ORMs, and found *Bun* which >>>> was indeed faster compared to Gorm. But then I explored documentation more >>>> and realized it doesn't provide enough function to make life easier, this >>>> ORM even doesn't have community I felt. >>>> >>>> 1. I want to know readers view regarding ORMs in Go. >>>> >>>> Let me tell you something, my project is a huge project, and I decided >>>> to use Golang for better performance. But now I feel I've to write a lot >>>> of >>>> code and slow/less-featured ORMs here making me irritated. >>>> >>>> 2. What do you guys suggest is go really good for large projects? >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/6addef83-3e2d-4b6c-b543-8127f5754f0en%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/6addef83-3e2d-4b6c-b543-8127f5754f0en%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/C487B8AE-D8EF-47AE-A06C-48AC422DFD07%40newclarity.net >>> >>> <https://groups.google.com/d/msgid/golang-nuts/C487B8AE-D8EF-47AE-A06C-48AC422DFD07%40newclarity.net?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/54284d0f-4dc1-4fd8-a181-af336a96b268n%40googlegroups.com.
