> 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/80a159ae-b660-4423-bdea-76edb3d72480n%40googlegroups.com.