Why are @valid_attrs @update_attrs and @invalid_attrs using atom/declared-types keys while controllers will pass along stringified params?

[thiagomajesk]

If you want to understand why Phoenix uses string keys in the params map, you might want to take a look at these answers for further clarification...

Map key is a atom or string

To elaborate a bit, the reason why map keys from external sources (like user input) are strings, is that atoms are not garbage collected and there is a set maximum amount of atoms available in the system. If you exceed that amount, the VM will crash. So that’s why you shouldn’t create atoms from user input for example.

When to use which data-structure?

Copy/pasted here for reference. I hope it doesn’t break any rule of ToS or copyright. If it does, feel free to remove the post or ask me to do it. Elixir Best Practices: When to Use Structs, String-keyed Maps, and Atom-keyed Maps Feb 2, 2016 • Pete Gamache Elixir, much like its foundation language Erlang and its syntactic muse Ruby, makes a distinction between character strings , like "hi_mom" , and atoms , like :hi_mom . Elixir also offers several ways to pass around key-value data. There’s M…

This is the same reason why is considered a bad practice to dynamically create atoms in elixir. You’ll find this recommendation in many threads in the forum btw.

Best practices to avoid Blind SQL Injection

Atoms are Not GC’d, and therefore the BEAM puts a limit on how many are allowed to exist. This limit is 2**20 by default. Therefore using String.to_atom/1 at runtime is considered a flaw. Instead String.to_existing_atom/1 is preferred or even better an explicit conversion function built from a whitelist.

Is this a correct way to avoid wasting or reaching the atom limit?

String.to_atom creates a new atom if one of its name wasn’t use before, which is dangerous for dynamic/unknown data. String.to_existing_atom does only allow you to convert strings to atoms when the atom already exists at that point via some other means of usage of it. iex(5)> str = "some_random_not_yet_used_atom" "some_random_not_yet_used_atom" iex(6)> String.to_existing_atom(str) ** (ArgumentError) argument error :erlang.binary_to_existing_atom("some_random_not_yet_used_atom", :utf8) iex(6…

---

About the scaffolded tests though, If I remember correctly when you cast your attrs, Ecto doesn’t care if you have string keys or atom keys as long as they are not mixed together.
However, this could be a problem if you are mixin string and atom keys inside your functions by updating the params map directly before it gets cast. To avoid this, just use string keys on your tests.