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

[thiagomajesk]

@tcoopman

To comment on the design itself. For me role and user can live in the same context and thus I see no issues in role being used in user

The “roles” context was merely an example, don’t get caught on the semantics of my example. If you make the claim that it’s supposed to be in the same context, the problem naturally will disappear. The constraint I’m putting in my example is that you must fetch data from another context, hence the boundary constraint. It might as well be another computed field that has nothing to do with the user directly.

@LostKobrakai

I’m not sure why you’d need the database here if the underlying enum is fixed. Basically all I see here is that the frontend would need to query the db for building a select with the correct translated names → enum values, but that’s presentation and unrelated to storing values

In the example I gave, the values are computed by the business logic, not inputted by the user (I’ve updated the answer before I submitted, maybe you’ve read a different version that does not explain why this won’t happen).

@LostKobrakai

Anyways: @tcoopman is correct in that you want a transaction around the fetching of valid roles per organisation. Changesets can do that with e.g. prepare_changes or you can wrap the insert in a multi/transaction on your own. All your options have a race condition.

Not actually (I explained why in my answer above). The way I understand, even though prepare_changes is a nice solution to wrap the changes in one single transaction, if we are talking about boundaries it still falls under one of the options I listed. Unless of course, if you are dealing with changesets in the context.

@LostKobrakai

This first example of yours would fail if we’d talk about params coming from user input. Changesets break when you supply a mixed string and atom keyed map. Therefore at most I’d suggest using one of your other options, because you don’t really want to deal with the string keyed params manually. It’s much simpler to cast the user input first and deal with anything else you want to do later. And given my example from the start of this post is much more aligned with the idea of validating data at the edges.

The first example has a typo, it should be: User.changeset(Map.put(params, "role", role)). I’ve explained that ecto does not support that here. Just to be crystal clear, can you exemplify how would you tackle this problem if not using one of the options I presented?

@LostKobrakai

And then the last part of your example: Coupling and how you deal with that. This is a much more involved topic and actually something more fitting for your other topic talking about DDD.

This is certainly a concern that I had and impacted how the team I’m working on chose to deal with data sanitization/ computing in our applications (by patching the params). Every single person touching the codebase had almost the same questions (we are all elixir newbies). Therefore, If having boundaries were not a problem, this issue would not appear in the first place. Even though the main question is about the test code, this actually reflects a deeper problem regarding how to organize the code and how to actually act on the values passed to contexts.