mattfara50
Ecto schemas in a project that is depended upon by multiple projects
I have a situation at work where two distinct Phoenix projects, A and B, duplicate the same schemas, since they truck in the same db tables. This is painful, since migrations must be done twice. My instinct is to make a sort of library project, C, which A and B would call as file dependencies. All the schemas would reside there. I understand that this might not be conventional, or that it would also be possible to merge the A and B into one (much) larger project, but I’m wondering if this dependency model is even possible. If so, what would you call out as drawbacks? What would you call out as benefits? I should say that I’m a rank beginner. Please simplify.
Marked As Solved
7rans
-
Correct. And that was a major motivation for this approach.
-
Yes.
-
It SoC’d the rest well too. Everything related to that database was test in C. C gets involved in tests for A (and B) but indirectly (integration testing basically).
-
Some people/organizations like monorepos but I tend to find clean separations easier on my mind. It’s important that they are clean separations though! C should straightforward and general.
-
Hmm… I don’t think it’s too much of an issue. I use a git dependency in A/B’s mix.exs. So that pulls it in just fine.
-
A little but not much. Again with a clear separation, C doesn’t change much once built out.
-
No defdelegate. I kept it very simple. C is almost all schema code, and some very general reusable queries. Not much else.
I think the question to ask is how strongly tied they are. If C could be useful for more then just A and/or B (at least hypothetically) then it probably makes sense.
Also Liked
7rans
I did exactly this and it does work.
But there is a BIG gotcha you have look out for. If you create a database repo in project C (which you probably will for testing and development), when you include project C in your dependencies for A or B its going to automatically try to connect with the database when you run A or B. (I don’t 100% know why, but it does.) I didn’t realize this and had setup a separate connection with the database in my “project A”. And I kept getting an error about a missing socket (even though I was using tcp) – it was Project C’s repo trying to talk to the database but hadn’t been fully configured.
The solution was to utilize the repo from project C and not try to recreate it in A or B. There is probably a way to do otherwise but this worked for me. FYI you still have to config C’s repo in project A (and B). I also added it to A’s (or B’s) supervision tree (though maybe that wasn’t necessary?)
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance










