Hi Experts,
I have a question about data type - :atom
To my understanding once an :atom is created, it will not be removed by Garbage Collector.
Then the question: is it possible to delete an :atom manually ?
Restart the vm. ^.^
Really though they cannot be deleted because they are interned strings used for node-to-node communication and quick matching. Removing them could easily break a lot of cache’s for node-to-node communication and more without expensively iterating and communicating intent to every-single-node.
Besides, you should never ever ever be creating atoms other than at compile or start-up time only, any other time is 99% of the time a bug.
2 Likes
Thank you for detailed answer!
Hm… let say I get some data from API via HTTPoision.
This data I will modify and save to database.
The data might change in the future , i mean the K in %{k,v}
What would be the best practice to handle this scenario ?
Should I use strings in both schema & migration ?
Or is there an another solution ?
It definitely won’t be an atom at least. ^.^
Everything that comes from the database is not an atom, strings will be strings, so that’s a non-issue in any case. 
Let say we create a table in migration file
def change do
create table(:models) do
# Personal Data
add :username, :string
add :display_name, :string
add :display_age, :integer
end
end
Similar thing will be in schema:
schema "user" do
# Personal Data
field :username, :string
field :display_name, :string
field :display_age, :integer
end
In both cases as a key I use :atoms
Once :atoms are created , they can be used anywhere in the APP.
This seems very efficient - especially if API does not change.
But what if API later will change data to:
:first_name
:last_name
I was planning to create new :atoms dynamically and delete un-needed.
If I cannot delete :atoms then what would be the right solution ?
I’m seeing that all your fields are marked as either string’s or integers.
If you are talking about the field names like :username and so forth, that is just used to automate bindings with the database, and a schema I really doubt would change to new and unique names often enough to warrant not hot-swapping, and if you are not hot-swapping anyway then it doesn’t even matter.
For note, a schema is just a simplified view helper to the database columns, and the database results are always returned as strings, just the schema simplifies things for you for ease of access. After all the schema definition only happens at start-up, not like new ones get created at run-time.
I’m not even sure how you would create new names dynamically for schema’s, what is your use-case and example?
Hm… as I am not so experienced in Elixir / Erlang, maybe I miss understand something.
Here is a probable scenario:
22.02.2018 - Currently, one API with version 1 , provides me 50 fields that I need to store in DB.
22.05.2018 - Or later (random date), the same API but with version 2 will provide 100 fields of data.
How to handle this type of scenario ?
Taking into account that after update of API from v1 to v2 the following is possible:
- 15 fields from V1 will not be relevant anymore
- 65 fields are new
The numbers are random, but point is still the same:
- many fields will not be relevant from v1
- many new fields would come in v2
Doesn’t matter. If you use them then use them, plus those numbers are so piddly that you’d never even notice (a single module compilation can potentially make a lot more than that). Unless you are dynamically making them at run time then don’t worry about it, and that is not at run time, that is entirely at compile time.
1 Like
That is the point, as of today I have no exact information about future fields, so I cannot create them in advance in compile time.
But you can create them later and compile it later. You wouldn’t be able to define a schema at run-time anyway. ^.^
1 Like
Makes sense
Then the solution would, if API changes to v2, then my APP would have to change to v2 
Indeedily. ^.^
You have to recompile anyway to update the code to handle it, which already means you are recompiling.
1 Like
