Any downsides to using the same table for multiple contexts?

[stefanchrobot]

@tomekowal

In the scheduling example, I believe you don’t need two contexts. If you want to schedule something for a user, do you need his name? Probably don’t. Unless you have business rules like “anyone named Andrew can’t book on Thursdays”. So you only need to identify which user does booking. You can pass only an id.

There might be the case where you really need the user in scheduling. Maybe there is a party only for adults. You can pass user.id and user.age to scheduling context but that starts to seem smelly. There might be more things you need later. In that case, you still don’t use two contexts. You duplicate the schema with only necessary fields in scheduling context (as in original question of this thread).

Since only one context should be responsible for writing data, create and update should almost always be one function call + handling errors.

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.

My users come to me with a token, not an id, so I do need to fetch the user. I guess I could use a plug here, but I’m not convinced. Also the authorization requiries querying across schemas, so I don’t see how I could stay in one context. Having a slimmed down duplicate of the schema sounds like an interesting idea to try out.

index and show is when things get murky. My controller asks for quite some data, so the dependencies are there - in the controller. I end up with an action that calls 5 functions. I think it crosses the line of being “thin”. Moving this out to a new context just makes it easier to test. But that doesn’t seem to add more coupling.