4 ms·
The Django ORM / migrations are still basically unmatched in happiness factor.
by jgavris 8mo ago
The Django ORM / migrations are still basically unmatched in happiness factor.
- hansonkd 8mo agoIts crazy to me after all these years that django-like migrations aren't in every language. On the one hand they seem so straightforward and powerful, but there must be some underlying complexities of having it autogenerate migrations. Its always a surprise when i went to Elixir or Rust and the migration story was more complicated and manual compared to just changing a model, generating a migration and committing. In the pre-LLM world, I was writing ecto files, and it was super repetitive to define make large database strucutres compared to Django.
- dnautics 8mo agowell in elixir you can have two schemas for the same table, which could represent different views, for example, an admin view and a user view. this is not (necessarily) for security but it reduces the number of columns fetched in the query to only what you need for the purpose.
- deleted 8mo ago[deleted]
- IceDane 8mo agoThere is no way to autogenerate migrations that work in all cases. There are lots of things out there that can generate migrations that work for most simple cases.
- etchalon 8mo agoDjango manages to autogenerate migrations that work in the VAST majority of cases.
- boxed 8mo agoThat's why you can do your own migrations in Django for those edge cases.
- frankwiles 8mo agoI end up needing to write a manual migration maybe once every other year in real world use.
- hansonkd 8mo agoThey don't need to work in every case. For the past `~15 years 100% of the autogenerated migrations to generating tables, columns or column names I have made just work. and i have made thousands of migrations at this point. The only thing to manually migrate are data migrations from one schema to the other.
- igsomething 8mo agoGoing from Django to Phoenix I prefer manual migrations. Despite being a bit tedious and repetitive, by doing a "double pass" on the schema I often catch bugs, typos, missing indexes, etc. that I would have missed with Django. You waste a bit of time on the simple schemas, but you save a ton of time when you are defining more complex ones. I lost count on how many bugs were introduced because someone was careless with Django migrations, and it is also surprising that some Django devs don't know how to translate the migrations to the SQL equivalent. At least you can opt-in to automated migrations in Elixir if you use Ash.
- limagnolia 8mo agoDjango doesn't force anyone to use the automatic migrations, you can always write them manually if you want to :)
- wiredfool 8mo agoThere are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
- cuu508 8mo agoCan you give an example how this would happen?
- wiredfool 8mo agoOk, from memory -- There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2]. So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration. When I've run into this is with data migrations, or if you're adding/assigining permissions to groups.
- brianwawok 8mo agoThere’s like an atomic flag you can pull it out of the transaction . Solves a lot of these issues.
- hansonkd 8mo agoDoes that affect the autogenerated migrations at all? Teh only time I ran into that issue as if I generated a table, created a data migration and then it failed because the table was created same transaction. Never had a problem with autogenerated migrations.
- advisedwang 8mo agoWhat a crazy design, why don't they just do pre1 do1 post1 pre2 do2 post2?
- Izkata 8mo agoThis doesn't sound at all familiar, are you sure you're not mixing it up with something else?
- dnautics 8mo agooh the automatic migrations scare the bejesus out of me. i really prefer writing out schemas and migrations like in elixir/ecto. plus i like the option of having two different schemas for the same table (even if i never use it)
- 3eb7988a1663 8mo agoI have never done it, but I believe you could setup multiple schemas under the same database -by faking it as different databases and then use a custom router to flip between them as you like. That sounds like the path to madness, but I do believe it would work out of the box.
- dnautics 8mo agosounds inconvenient and error-prone
- 3eb7988a1663 8mo agoIt is not much code to setup the router. Now, why you would want to bounce between schemas, I do not have a good rationale, but whatever floats your boat.
- dnautics 8mo agoyeah some frameworks call these "lenses". There's even crazy people who write lenses on top of elixir schemas because they dont realize you can just have multiple schemas. maybe more concretely: if you have a table with a kajillion columns and you want performant views onto some column (e.g. "give me the metadata only and dont show me blobs columns") without pulling down the entire jungle in the sql request, There's that.
- gtaylor 8mo agoThe nice thing in this case is that Django will meet you where you are with your preferences. Want to go the manual route? Sure. Want it to take a shot at auto-generation and then you customize? Very doable and. Want to let Django take the wheel fully the majority of the time? Sure.
- danmaz74 8mo agoHave you ever tried Rails? I think that Django's approach on those is an adaptation from it.
- jgavris 8mo agoOf course, ActiveRecord back in 2005.
- ndr 8mo agoI found it very lacking in how to do CD with no downtime. It requires a particular dance if you ever want to add/delete a field and make sure both new-code and old-code work with both new-schema and old-schema. The workaround I found was to run tests with new-schema+old-code in CI when I have schema changes, and then `makemigrations` before deploying new-code. Are there better patterns beyond "oh you can just be careful"?
- senko 8mo agoYou can do three stage: 1. Make a schema migration that will work both with old and new code 2. Make a code change 3. Clean up schema migration Example: deleting a field: 1. Schema migration to make the column optional 2. Remove the field in the code 3. Schema migration to remove the column Yes, it's more complex than creating one schema migration, but that's the price you pay for zero-downtime. If you can relax that to "1s downtime midnight on sunday", you can keep things simpler. And if you do so many schema migrations you need such things often ... I would submit you're holding it wrong :)
- jgavris 8mo agoI was just in the middle of writing something similar above, thanks!
- ndr 8mo agoI'm doing all of these and None of it works out of the box. Adding a field needs a default_db, otherwise old-code fails to `INSERT`. You need to audit all the `create`-like calls otherwise. Deleting similarly will make old-code fail all `SELECT`s. For deletion I need a special 3-step dance with managed=False for one deploy. And for all of these I need to run old-tests on new-schema to see if there's some usage any member of our team missed.
- jgavris 8mo agoThe general approach is to do multiple migrations (add first and make new-code work with both, deploy, remove old-code, then delete old-schema) and this is not specific to Django's ORM in any way, the same goes for any database schema deployment. Take a peek at https://medium.com/@pranavdixit20/zero-downtime-migrations-in-django-the-advanced-playbook-742d85f1f5c0 https://medium.com/@pranavdixit20/zero-downtime-migrations-i... for some ideas.
- Humphrey 8mo ago100% I am quite surprised that most languages do not have an ORM and migrations as powerful as Django. I get that it's Python's dynamic Meta programming that makes it such as clean API - but I am still surprised that there isn't much that comes close.