Using Cachex in Phoenix - working example?

Phoenix Forum Questions / Help
,
1

I’m new to Elixir and Phoenix and I’m trying to implement Cachex. I’m struggling to get this working. I added the dependency to my mix.exs and I modified my application function so it references the Cachex app:

def application do
    [
      mod: {MyApp.Application, []},
      extra_applications: [:logger, :runtime_tools],
      applications: [:cachex]
    ]
  end

deps.get downloaded the package and that all seems to be working.

In my application.ex, I have tried to add the appropriate block to the Supervisor.start_link:

  def start(_type, _args) do
    import Supervisor.Spec

    # Define workers and child supervisors to be supervised
    children = [
      supervisor(MyApp.Repo, []),
      supervisor(MyApp.Endpoint, []),
      worker(Cachex, [:my_cache, []]),
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
    
  end

As soon as I try to run the server, I get an error:

mix phx.server
Compiling 16 files (.ex)
Generated my_app app

=INFO REPORT==== 12-Feb-2018::15:32:28 ===
    application: logger
    exited: stopped
    type: temporary
** (Mix) Could not start application my_app: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: MyApp.Repo
    ** (EXIT) exited in: GenServer.call(Ecto.Registry, {:associate, #PID<0.367.0>, {MyApp.Repo, MyApp.Repo.Pool, [name: MyApp.Repo.Pool, otp_app: :my_app, repo: MyApp.Repo, timeout: 15000, pool_timeout: 5000, adapter: Ecto.Adapters.MySQL, username: "my_user", password: "xxxxx", database: "my_db", hostname: "my.host.tld", pool_size: 10, pool: DBConnection.Poolboy]}}, 5000)
        ** (EXIT) no process: the process is not alive or there's no process currently associated with the given name, possibly because its application isn't started

I’m not sure why it is choking. I can at least compile the app and start the server if I add :cachex to the “extra_applications” instead of to the “applications” bit. Can someone shed some light on this? Is it viable to use extra_applications instead?

2

I solved the above by using “extra_applications” instead of “applications” (but not both), but still, I haven’t actually gotten a working example. E.g. in my context, I have something like this:

def get_cached_result!(slug) do

    Cachex.fetch(:my_cache, "key", fn(slug) ->
      Repo.get_by!(MyRecord, slug: slug, parent_id: 0)
    end)

  end

But that generates an error:

function Cachex.fetch/3 is undefined or private

3

Your primary problem is outdated information for cachex. Elixir used to require you to manage the applications key yourself but starting around 1.4 (I think) it manages it for you. When you choose to manage that key explicitly, then you need to manage it for all deps. The first thing I’d recommend is to try without cachex in any of the application keys, and just put it in deps.

2 Likes
4

Thanks! I got that one figured out after some trial and error, but I’m still at a loss as to how to make it actually work. I’m hoping that if I can get something working I can at least make a pull request to submit some examples or clarifications to the docs…

5

try with Cachex.get - not sure a fetch exists - Cachex — Cachex v3.6.0

so maybe:

def get_cached_result!(slug) do

    Cachex.get(:my_cache, "key_#{slug}", fn(slug) ->
      Repo.get_by!(MyRecord, slug: slug, parent_id: 0)
    end)

end

fwiw I have this from some old code (untested recently):

{ _status, post } = Cachex.get(:my_cache, "post_#{id}", fallback: fn(_params) ->
  Post
  |> Repo.get!(id)
  |> Repo.preload([:comments])
end)

EDIT: from a quick look: fetch is being added in Cachex 3.0 - so thats probably why you find it on the github examples:/

3 Likes
6

Ah, ok, I stumbled into the v3 docs without knowing it. Treacherous docs!

I’ve refactored to use the get function to something like this

  def get_cached_menu!(slug) do
    Cachex.get(:my_cache, slug, fallback: fn(slug) ->
        Repo.get_by!(MyThing, slug: slug)
    end)
  end

That compiles but it throws an exception at run-time:

** (exit) an exception was raised:
    ** (UndefinedFunctionError) function :loaded.slug/1 is undefined (module :loaded is not available)

Why is “slug” being seen as a function? Is my Ecto Repo module not in scope in the callback?

1 Like
7

Because the return from Cachex.get(...) is not the raw value, but rather a tuple of success status. :slight_smile:

As I recall it returns either {:ok, value} for a value in the cache, or it returns {:loaded, value} for a value that was not in the cache but is not in the cache via a fallback and thus returned that, or it returns {:missing, nil} if it failed to acquire it from cache or a fallback. :slight_smile:

As you can see, it is accessing :loaded.slug, which matches the {:loaded, slug} return tuple. :slight_smile:

1 Like
8

Ah, ok, that makes sense. I think I should submit a PR for the docs on that.

I ended up with something like this:

  def get_cached_thing!(slug) do
    {status, thing} = Cachex.get(:my_cache, slug, fallback: fn(slug) ->
        Repo.get_by!(Mything, slug: slug)
    end)
    case status do
      :loaded -> thing
      :error -> "That thing does not exist"
    end
  end

That works, but I’m open to any comments/improvements/suggestions. Not sure how idiomatic that solution is. Thanks!

9

It’s already documented at:
https://hexdocs.pm/cachex/Cachex.html#get/3

:slight_smile:

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

1 Like
10

Honestly, I didn’t see that page – note that the links from https://github.com/whitfin/cachex 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!

11

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:
https://hexdocs.pm/cachex/api-reference.html

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:
https://hexdocs.pm/cachex/Cachex.html

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

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

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

2 Likes
12

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

3 Likes
13

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?

14

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

15

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 Like
16

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 Likes
17

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?

18

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: