-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hooks should be provided access to the Worker state #1
Comments
This is a bit of a pain, because hooks have to be built and started before the worker actually is... so the irony is the worker doesn't even exist during start up. So... Need to think of another way around it. Considering an option to pass into a hook of This is kinda gross, but it does lend itself to backwards compatibility well. defmodule MyModule.WorkerHook do
use Cachex.Hook
def init(args) when is_map(args) do
{ :ok, args }
end
def handle_modify({ :worker, worker }, state) do
{ :ok, Map.put(state, :worker, worker) }
end
def handle_notify(_action, state) do
{ :ok, IO.inspect(state) }
end
end |
Ok I have this working now... I'll just neaten it up a bit and get a PR in. It's not the nicest interface, but I expect it to be less frequently used, so it shouldn't matter too much. |
Hit a bug with overriding |
As it currently stands, there is no way to call a cache from within a hook callback. This could prove valuable for synchronous hooks - i.e. you might want to retrieve a key quickly before it's removed.
As of v0.9.0, the Cachex interface accepts a worker and does not have to pass between procs to execute actions. This means that we can allow cache calls inside hooks using the worker, and everything should flow smoothly.
I'd imagine the best way to do this is to pass the worker into
init/1
and allow the developer to choose whether to keep it around or not.The text was updated successfully, but these errors were encountered: