3 ms·

> I do wish migrations were just generated from schemas though, a la Django. This is a weird one to me. I really dislike the magical way Django does this and I

• arrowsmith 3y ago
  Agreed, I hate the way Django does it. I don't want my database migrations to be tightly coupled to my models - what's the point? I'm not sure that the Django approach would make sense in Ecto anyway because Ecto schemas are explicitly _not_ "models". The function of a Django/Rails "model" is divided between different concepts like schemas, Ecto.Query, Ecto.Changeset, the Repo etc.
  • freedomben 3y ago
    Same. I was annoyed at first with what felt like duplication (and indeed is duplication for the first time the table is created), but over time the Ecto/Elixir method really showed it's merit and is IMHO the cleary superior way for a maintainable long-term application. The magic and the convenience in the short term it brings are not worth it. The straight forward, explicit and crystal clear declarative way for migrations and the schema are IMHO a joy.
• bmelton 3y ago
  Ash Framework gives you the ability to define the schema in code, via mix ash_postgres.generate_migrations --name name_of_my_migration but of course now you're using a framework (albeit a really good one) that is perhaps a bit less mature than Elixir
  • ch4s3 3y ago
    I'm aware of that, and can see why people like it in Ash, but as with Django I think it makes things less explicit, harder to break up domain specific structures backed by the database, and more magical. It's fine IMHO as an add on with something like Ash, but a data mapper like Ecto shouldn't strive to be an ORM like Django especially in a functional language.
  • zachdaniel 3y ago
    I think its also important for people to realize that 1. its opt-in, if you don't like it don't use it :) 2. we don't do magic migrations. We generate a regular ecto migration from your resource changes. So you can use it as a starting point and hand edit it (and often you should or even must as we can't do things like generating data migrations). 3. you don't have to map your resources one-to-one with tables. We support multiple resources being sourced from the same table, and turning on and off migration generation per resource. It's very common to have an Ash resource backed by a postgres view, or two ash resources backed by the same table. The migration generator merges resource definitions together to create "the strictest table definition that supports both resources". You can also remap field names. So at the end of the day, you can have your cake and eat it too on that front.
• sergiotapia 3y ago
  Prisma does the same thing and it sucks to me. Always a pain to figure out what happened when things don't work as you expect them to.
• conradfr 3y ago
  I mean that could just be a mix task that you would be free to use or not. Currently it's true (for me) that writing the migration is copy pasting the fields from the ecto schemas and modifying them because the dsl is "almost the same but not totally".