jwsinner
From what I can gather, Registry is a way to localize keys to make using OTP stuff a bit easier. This is especially important when you want to use a binary key for a GenServer or Agent instead of an atom or setting it to {:global, key}.
That said, and I’m chalking this up to my own ignorance, it seems to be HIGHLY unintuitive to use. In my mind Registry is basically a supervised key/value store (like a map, but backed by an ets table) where the key responds to a {pid, init_value} tuple (or list of tuples if :duplicate is used). So when we have a function called keys, it makes sense that I’m looking for the keys within that Registry, especially since Registry.count/1 takes in the name of the Registry and returns the number of keys… Instead, we’re expected to also pass along the pid, to get the key(s) associated with it? If I’m using Registry as a way to make GenServer or Agent easier to use (not having to know the pid to pass along), why do I need to know the pid to pass along?
Similarly, Registry.values requires the registry name, a pid, AND the key? Does Map.values/1 require anything other than the map?
I understand there needs to be a difference in usages based on :unique vs :duplicate, but that seems like it could be solved via pattern matching. I like the idea of Registry, but it seems VERY clunky to use for what it’s trying to do. Am I just super ignorant of the underlying mechanisms? If so, I’d love some clarification so I can better understand where I’m falling short.
Where Next?
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All Posts (oldest first)
- Show All Posts (newest first)
LostKobrakai
I think the part you’re missing here is that it’s generally expected that both ends – registered processes and processes interested in registered processes – know what keys they’re interested in. That would be the very same as with other registries – local atom names or
:global.Registry.keysandRegistry.valuesare not meant as general tools to finding all keys or all values that are currently registered – besides the fact that this could potentially be quite an expensive operation. They’re much rather helpers for figuring out how a process in question is related in the registry, but you generally wouldn’t used them to interact with registered processes.Registry.lookup,Registry.match,Registry.selectare the APIs you’re expected to use to query the registry (in order of complexity).entone
I think one other use case that you are missing is the ability to use multiple Registries, which would require knowing the registered name or pid of that individual Registry. So the design of Registry is specifically to allow multiple Registries.
jwsinner
Thank you. This does clear up a few things.
I think the confusion comes from the documentation:
If it’s a key-value storage mechanism, it feels like it should behave a lot like the other “go-to” key-value storage mechanism. But I see how having to concatenate the partitions (if partitioned) would be very expensive if
keysorvalueswas used a lot.I guess I have a sweet tooth and would prefer a bit more syntatic sugar over the Erlang abstractions.
jwsinner
Since it’s a key-value storage mechanism, it feels like it should behave like one.
Map.keys/1andMap.values/1are trivial to use because I just pass in the map I want. It seems likeRegistry.keysshould take in the name associated with the registry created in the supervisor, soRegistry.keys(MyApp.GroceryRegistry)should return all of the keys available that have been registered either throughRegistry.registeror{:via, Registry, {MyApp.GroceryRegistry, [name]}.Instead, to get the available keys, we have to use the Erlang match pattern syntax on a function named
select. If it’s a key-value storekeysshould return the list of keys andvaluesshould return the values.That said, as LostKobrakai mentioned, it’s more about process discovery and use and those processes will know about each other. It’s not supposed to be used EXACTLY like a Map.
josevalim
It is a key-value process storage. So you can think of it having three dimensions (key, value, pid), instead of two, and, it also allows duplicate keys with a single process. The process bit is crucial, it is not simply a key-value storage.
If that’s your goal,
:etstables are most likely a better choice.