Using Cachex in Phoenix - working example?

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.

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?

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

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!

@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?

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?

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

I found that doc by going to Cachex’s dependency hex page (the first page I go to for any library):

Then I clicked the link that stated Online documentation, which took me to:

Which I then switched to night mode because Ow My Eyes… o.O
It shows two modules, they are:

• Cachex

  • Cachex provides a straightforward interface for in-memory key/value storage

• Cachex.Disk

  • This module contains interaction with disk for serializing terms directly to a given file path. This is mainly used for backing up a cache to disk in order to be able to export a cache to another instance. Writes can have a compression attached and will add basic compression by default

I then clicked on the top one as it’s the main interface for it, which took me to:

In the functions section I clicked the get function and it took me to the link I linked.

‘Almost’ every hex library has their docs on hexdocs at a path of https://hexdocs.pm/<library_name> for note, which is linked from Hex as well (specific versions if you want too).

But yep, it’s linked on the front-most hex page of the library itself.

Honestly, I didn’t see that page – note that the links from GitHub - whitfin/cachex: A powerful caching library for Elixir with support for transactions, fallbacks and expirations · GitHub do not point to that page, and starting from https://hexdocs.pm/ did not lead me there in any sort of purposeful way (i.e. if you didn’t know what you were looking for already, it’s unlikely you’d end up there), so I hopefully can be forgiven for not finding it. Also, the examples there do not include code for handling the tuples. Yes, of course, if you know what you’re doing that’s a trivial omission, but for noobs, that’s one more snare that might get you. I hope I’m not just speaking for myself by wanting the example to include just a bit more context.

Thank you for the suggestions re idiomatic code! Very helpful and much appreciated!

It’s already documented at:

It works fine but not very idiomatic, I’d personally do it like (well I generally have the fallback built into the cache rather than on each call, but ignoring that part):

  def get_cached_thing!(slug) do
    Cachex.get(:my_cache, slug, fallback: fn(slug) ->
        Repo.get_by!(Mything, slug: slug)
    end)
    |> case do
      {:error, _} -> nil # It's not common to return error strings, rather you'd probably want an error tuple
      {success, value} when success in [:ok, :loaded] -> value
    end
  end

Or maybe using ok/error tuples, whichever.