The very simple :ets wrapper simplifying cross-process :ets handling (like Agent, but :ets.)
NimbleETS is a very thin simple ETS wrapper, simplifying the trivial usage of ETS as key-value store. It is not intended to replicate :ets module functionality by any mean. It might be used as a drop-in to avoid process-based Agent as key-value store. It exposes onlyCRUD functionality of ETS, alongside with Access behaviour.
defmodule MyApp.MyModuleBackedByTable do
use NimbleETS
end
MyApp.MyModuleBackedByTable.ets_put(:foo, 42)
MyApp.MyModuleBackedByTable.ets_get(:foo)
#⇒ 42
MyApp.MyModuleBackedByTable.ets_del(:foo)
MyApp.MyModuleBackedByTable.ets_get(:foo, :bar)
#⇒ :bar
Hmm, Nimble* projects in the elixir ecosystem generally mean things that are the fastest possible implementation of something, how does this make ETS operations faster?
I had initially have called it NimbleAgent, then I realized it has nothing to do with Agent and I finally screwed the name totally up. It obviously does not make :ets any faster, but it also does not make it any slower, but the development process becomes faster.
Heh, following the pattern of Jose’s Nimble* libraries the development is often ‘slower’ than other libraries, but it ‘executes’ faster, it’s all a trade-off. ^.^
I’ll probably revoke the package during the weekend and re-deploy it as NimbleAgent as in was intentionally supposed. Nobody needs to know that there is :ets behind and it’s indeed notably faster than Agent on significant amount of CRUD operations.
It would indeed be a faster agent for setting/retrieving information, but that’s not what Agents are for. Agents are to do some processing of data on the agent state in another process so it doesn’t block your own process or for synchronization reasons (otherwise using ETS just for multi-process data storage with, say, the Eternal library for ease of use). If this uses ETS to do operations with no backing process then any functions called would need to be run in-process, thus blocking the existing process.
Like from the Agent docs itself:
# Compute in the agent/server
def get_something(agent) do
Agent.get(agent, fn state -> do_something_expensive(state) end)
end
# Compute in the agent/client
def get_something(agent) do
Agent.get(agent, & &1) |> do_something_expensive()
end
It uses this as an example of this, where the top does the expensive operation in the agent and the second does it in the caller, either of which can be preferred depending on what the purpose is, but if an ETS data store is used then I’m not sure how you could call operations on the Agent side without blocking your own process (like using Agent.cast/2,4). Agent’s aren’t just for holding data, you can use ETS for that, Agents are for running operations on that data in another process synchronously, and I don’t see how you could do that on a pure ETS table without a backing process?
The package was renamed to EasyETS, thank you all.
The backing process is planned in 0.2.
My goal is to bring the operational semantics to be more or less the same as Agent has in the forthcoming updates. I posted the very alpha version to gather advises and thanks I received all I wanted.
Yes, thank you, I came to the exactly same name. All done.
