> 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.

Reply via email to