Any downsides to using the same table for multiple contexts?

[baldwindavid]

@sasajuric

I used ids here mostly b/c I assume the client is the web tier which doesn’t have the user struct

Understood. I usually have a struct because I have grabbed it to authorize.

@stefanchrobot

Let me chime in with a question: how thin are your controllers really?

They are generally pretty thin, I think. In a lot of admin areas they are authorized at router level, so it is a simple case statement.

Other areas have per action authorization which adds a with. Anything more intensive typically takes place in whatever context function is being called. Some of these functions within the context end up as big multis. In a few cases, a user is passed to the context function for authorization. That is typically to use a different changeset based upon user permissions.

@stefanchrobot

But as a result a new context emerged - a context that’s tailored for the specific controller. Since that controller is not tied to a single schema, but a use case, so is the context. Which means that it depends on other, simpler contexts (like Accounts , Schedule , etc.). What do you think about this approach? Do you happen to have similar things (more complex contexts; contexts dependant on other contexts) in your codebase?

I think as I refactor a bit, I will likely end up with some cross-context, um, contexts. The Phoenix docs talk about this a bit at the end… Contexts — Phoenix v1.7.10

@tomekowal

I also try not to overcomplicate stuff for the sake of some future benefits because the future might never come. I focused on the ability to refactor DB structure because that bit me hard one time and because of the original question of @baldwindavid concerned schemas.

I appreciate the information and can experiment and learn even if I’m not going to use it right away. It is good to have that as a potential route when I encounter a situation where the defaults aren’t quite cutting it.

@tomekowal

index and show can often read stuff from multiple contexts to display it nicely for the user. Showing user.name next to schedule sounds like a good idea So those would be two separate calls in the show action.

To be clear though, I am absolutely duplicating the user name in a Calendar.User schema. I will not be planning to write the user name from the Calendar context, but will definitely read from it. Perhaps that right there is one of the issues with using the same table with multiple schemas though. If you can/should only update a given column/field from a single context, you don’t immediately know in a given context whether a field can be written to or should be read-only.

Anyway, to me, the beauty of the ability to use the same table for schemas in multiple schemas is that I can more easily reason about in whatever context I’m currently in. Quickly skimming the schemas within the Calendar context shows most of the data used in the context. Context-specific authorization can be performed directly on structs within the calendar context.

It’s not to say I won’t/don’t reach out to other contexts/services when it makes sense, but contexts mostly being able to operate on their own feels pretty nice. As a side benefit, it might make it easier to break these a contexts off on its own app in the future. That is not the reason I’m doing it though. It is attempting to (maybe even wrongly) make it easier to understand and, ultimately, more maintainable.

@tomekowal

Amen! Ecto is fantastic! It makes easy things easy and hard things still doable!

Agreed. Regardless of the direction I’m going now, I don’t feel particularly locked in to anything. Ecto and Phoenix are both light and flexible and changing things often just comes down to changing some module names.