Fix select_count edge case of raising an exception #357
Conversation
…eturn any rows which will raise an exception instead of returning a value. Fixes #297
| @@ -182,6 +182,8 @@ module Avram::Queryable(T) | |||
| def select_count : Int64 | |||
| query.select_count | |||
| exec_scalar.as(Int64) | |||
| rescue e : DB::NoResultsError | |||
| 0_i64 | |||
There was a problem hiding this comment.
We're currently doing this thing where we log when a query fails. I wonder if it would be strange to still return this value, but also throw a warning log saying something like "Hey, you just ran this query BLAH, but it's not doing what you think it should be....".... In my case, that may flood the logs a bit, but just a thought..
There was a problem hiding this comment.
I think this is fine if I understand this correctly. It seems like the query would not raise if there were items right? In other words the query is valid and it just didn't have results because there weren't any? If that's the case then I think this is great.
Otherwise I almost think this should raise and we have a `select_count!
There was a problem hiding this comment.
Yeah, exactly. If you have records to return, then you get that number back, but if there's no records, then instead of getting 0, PG gives you nothing. Something to do with how groups work probably. Like, no groups returned, so there was nothing to count on.
There was a problem hiding this comment.
Gotcha. I think 0 makes sense without a log then. If we do decide to log at some point we can add a new log class so it’s easy to disable/enable. But that can wait until someone wants it. Imo this is the expected behavior so is probably fine
Fixes #297
In a more complex case, postgres won't return any value when trying to do a count. This causes DB to just raise an exception instead of returning 0.