fireproofsocks

fireproofsocks OP

Thank you for your patient guidance – it helps, and in retrospect, it all seems obvious.

3
Post #11
outlog

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
Post #12
OvermindDL1

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? :slight_smile:

0
Post #13
outlog

outlog

I was thinking @fireproofsocks could test it for us :smiling_imp: [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
Post #14
outlog

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
Post #15
fireproofsocks

fireproofsocks OP

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
Post #16
OvermindDL1

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

0
Post #17
— All posts loaded —