ketupia
I find myself writing this code repeatedly. Is there a better way
if Status.exists?(entity) do
Status.update(entity, new_value)
else
Status.add(entity, new_value)
end
Where Next?
Trending in Questions
Other Trending Topics
Latest in /ECSx
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
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 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tfwright
Can you provide a bit more context about what could be “better” in your view? Obviously you could wrap that code in a function and call that function instead, but I assume you are looking for something a bit more sophisticated?
ketupia
Something out of the box provided by the ECSx.Component.
maybe add the wrapper method you suggested to the ECSx.Component macro
maybe update would add it if it didn’t exist. If there’s a need to raise errors from update if doesn’t exist, include an update! function
maybe add would update it if it did exist. If there’s a need to raise errors from add if it existed, include an add! function
smathy
Ironically,
:etshas only a singleinsertthat either adds or updates (overwrites). As you can see in the sauce the main difference betweenaddandupdateis essentially just a guard to prevent existing elements from being overwritten, or non-existing elements from being auto-created.There’s no
upsertoperation, might be worth submitting a PR.APB9785
As @smathy pointed out, :ets inserts generally allow overwrites, and this was originally how ECSx worked as well, with just a single
addoperation that covered both cases. The reason we separated into two functions, is because of component persistence. Take the following case:The first operation inserts a persistent HitPoints component with value
100The second operation overwrites this with a non-persistent (default is false) HitPoints component with a value of
95.What was the problem? If a user provides options to the component creation, they would have to remember those options and pass them to every update, forever. Forgetting to include the original options would overwrite with the defaults. We considered setting the options globally, but quickly found use-cases where a single component type (such as HitPoints) would be persisted for some entities, but non-persisted for others. And we want to keep the door open for future options to be added.
So the end result is that we need one function for the original creation of a component, where the options are set, and then another function for updating the component, where no options = keep the existing options.
smathy
Makes sense. Did you consider storing the opts in ETS along with the value?
APB9785
The opts are stored in ETS. It’s not an implementation issue, it’s an API issue - with only one function for both add and update, it becomes ambiguous whether a user is leaving off the options because they want the options to stay the same, or if the lack of options means that they want the defaults. The only way to ensure consistency would be to demand that users include the options every time.
smathy
Oh I see what you’re getting at. I’m not sure people would expect that though (ie. that leaving options off for an existing entity would change it to the default).
Also, right now the current API doesn’t let them change the options of an existing entity at all, so you wouldn’t lose any functionality with an
addthat just left the opts as-is for an existing entity when the caller left them off.Then if they wanted the opts updated on an existing entity, they’d provide the opts, which would be additional functionality.
I think the problem you saw was maybe doing an
:ets.insertwithout doing a:ets.lookup. Obviously with that implementation you’d be clobbering existing opts for an update if they hadn’t provided them.Or am I just missing something dumb here?
APB9785
This isn’t guaranteed to be the case forever.
If the default functionality is “keep the existing value” then it doesn’t work for creating new components (because there is no existing value yet). And we cannot have two different default functionalities for the same function, based on a runtime conditional. That would be very bad.
smathy
Understood.