tim2CF
Let’s say we have a code
iex(1)> Phoenix.PubSub.subscribe Foo.PubSub, "user:*"
:ok
iex(2)> :erlang.process_info(self, :messages)
{:messages, []}
iex(3)> Phoenix.PubSub.broadcast Foo.PubSub, "user:1", :foo
:ok
iex(4)> :erlang.process_info(self, :messages)
{:messages, []}
Looks like phoenix_pubsub does not support asterisk symbol - "user:*" or "user.*" not worked for me. Is there any fundamental reason why it don’t support this functionality? Will be very useful for models/topics with big amount of fields (where amount of possible permutations is huge) like "user.*.currency.BTC.country.*"
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
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 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
benwilson512
@tim2CF it’s not supported because explicit support isn’t necessary, you can just publish to a
user:*"topic every time you call publish and voila, now you have support for that. Topics are simple strings with no implicit structure which allows you to handle any approach you want.tim2CF
@benwilson512
Let’s say we have some simple transaction ecto model with 2 fields (for simplicity of example) - user and currency. And we want notify process when transaction happens.
Process A wants to receive messages related to
user: 1with any currency and process B wants to receive messages related tocurrency: BTCand any user, so topics which they are listening will beuser.1.currency.*user.*.currency.BTCand when event with
user: 1andcurrency: BTCactually happens - I want just emit it once in my code with routing keyuser.1.currency.BTC- but with currentphoenix_pubsubimplementation message will not be delivered to A or B. To make it actually work I need to emit event multiple times with different keys:user.1.currency.BTC+
user.*.currency.*+
user.1.currency.*user.2.currency.*user.3.currency.*…
+
user.*.currency.BTCuser.*.currency.USDuser.*.currency.EUR…
Which obviously gives huge overhead even with amount of fields = 2. But with bigger amount of fields complexity and overhead becomes unacceptable.
benwilson512
What’s the overhead of splat matching? What’s the proposed mechanism for making that work that incurs less overhead?
easco
I believe the ability to use the
*wildcard is a feature of Phoenix Channels, and not built into the PubSub system itself. When creating a channel you can tell Phoenix that you want a particular Channel module to handle all the broadcast messages matching a particular pattern, but I don’t think you can subscribe to a PubSub with wildcards.