Thank you for your patient guidance – it helps, and in retrospect, it all seems obvious.
fireproofsocks
outlog
one question.. does Cachex swallow the get_by bang (get_by!) in case it doesn’t find any?
Repo.get_by!(Mything, slug: slug)
or does it blow up?
0
OvermindDL1
@outlog Fantastic question! I don’t actually know, I don’t throw exceptions or use exception throwing functions… ^.^;
/me wraps about everything that can throw exception or errors to return error tuples instead, very much prefer error tuples except in truly exceptional error conditions, which a database failure is not
You should test it? 
0
outlog
I was thinking @fireproofsocks could test it for us 
[quote=“OvermindDL1, post:14, topic:12458”]
@outlog Fantastic question! I don’t actually know, I don’t throw exceptions or use exception throwing functions… ^.^;
[/quote]
well me neither - but could save some lines of code here if cachex does indeed swallow the get_by!
1
outlog
it does blow up with a bang.. so a bit more defensive code is needed, unless you are doing bangs on purpose..
if you simply remove the bang and use get_by it will return nil on not found, and that will be cached - depending on your caching strategy you might not want that - and you can use the ignore feature.. that way the nil/not found is not cached and the db is always queried on slugs that are not found - but it all depends..
here is an example.. using :ignore so the nil is not cached.. else just remove the bang in get_by
def get_cached_thing!(slug) do
Cachex.get(
:my_cache,
slug,
fallback: fn slug ->
case result = Repo.get_by(Mything, id: slug) do
%Mything{} ->
# happy path - commit to cache
{:commit, result}
nil ->
# not found - ignore tuple so it's not cached
{:ignore, nil}
end
end
)
|> case do
# It's not common to return error strings, rather you'd probably want an error tuple
{:error, _} ->
{:error, "error - devops needed?"}
# the ignore returns an :loaded tuple - so match nil
{:loaded, nil} ->
{:error, :not_found}
{success, result} when success in [:ok, :loaded] ->
{:ok, result}
end
end
3
fireproofsocks
This is really helpful. By avoiding the “!”, the requests for which no record exists will return an error. However, this results in an HTTP 500 error… how can I change that so it returns a 404 (or any other http status code)? Are there special atoms that trigger that in Phoenix? How does that bit of error handling work?
0
OvermindDL1
It’s in the error handling section of the phoenix docs, you can either explicitly state what error in the conn and then return the conn, or you can raise an exception that specifies to phoenix what error to return.
0