Yeah, basically have a and b own their respective Ecto.Repos, then any shared data manipulation can be extracted to shared. In other words, can you avoid hitting the db from app_shared?
Most of the api in shared is simple - get_user_by_id, get_user_by_name etc. There is nothing complicated to extract except connect to the repo and do its thing. All I can think with my limited experience in Elixir is to pass in the repo from each app on every function call. Beyond that, there could be things that could be done in a smart way - polymorphism, figuring out the calling app somehow and having a central genserver provide the right repo. The problem though is, how would the shared app function know “who” is calling without explicitly telling it on each function invocation? How would shared_app know whether app_a is calling it or app_b is calling it. If there is a way to do it then that would solve the problem. I don’t know of a way.
I don’t know the answer to this myself, but if you create a __using__ macro in module A and then use that module in module B, can you access one of B’s constants from the code in __using__? If so, you could just define a constant in the modules that use module A, which A could reference to get the repo.
Often in situations where you have multiple apps in the umbrella that depend on the same database I opt to break out another app, which I often call db that acts as a single place to contain migrations and also repository configuration. Then you can depend on this db app in app_a / app_b and app_shared.
@cjbell - The situation is slightly different here. Its different db in the different apps (app_a and app_b) with some shared code (app_shared). I was trying to avoid passing in the repo into the shared code on every function call from app_a and app_b. I can’t seem to think of a way. Macros perhaps - but all of shared code should be built with macros then and used in app_a and app_b. There isn’t a way to configure app_shared to say - if you are app_a, then use repo_a and if you are app_b, then use repo_b. Since this information is known upfront and we don’t have to wait till runtime to know it, it would be nice if there was a way to figure out somehow which repo to use in app_shared depending on the app making the function call.
