oh 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)

▲

dxdm 20 hours ago | parent | next [-]

You can ask Django to show you what exact SQL will run for a migration using `manage.py sqlmigrate`.

You can run raw SQL in a Django migration. You can even substitute your SQL for otherwise autogenerated operations using `SeparateDatabaseAndState`.

You have a ton of control while not having to deal with boilerplate. Things usually can just happen automatically, and it's easy to find out and intervene when they can't.

https://docs.djangoproject.com/en/6.0/ref/django-admin/#djan...

https://docs.djangoproject.com/en/6.0/ref/migration-operatio...

▲

gtaylor a day ago | parent | prev | next [-]

The 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.

▲

dnautics 10 hours ago | parent [-]

is this like the "it takes 50 hours to set up a project management tool to work the way you want"? what happens if you onboard a superstar that works with django some other way?

	▲	lmm 3 hours ago \| parent \| next [-]
		No. Django is very good at having the autogenerated/default stuff be consistent with what you do if you want to write manually, it's not one of those "if you want to use the magic as-is it all just works, if you want to customize even one tiny piece you have to manually replicate all of the magic parts" frameworks.
	▲	Izkata 5 hours ago \| parent \| prev \| next [-]
		Either way the end result is a single file in migrations/ that describes the change, though you do have to write it with Django's API if you want further migrations to work without issues (so no raw SQL, but this low-level API is things like CreateTable() and AddColumn() - and is what Django generates automatically from the models, so the auto-generated migrations are easily inspectable and won't change).
	▲	Nextgrid 7 hours ago \| parent \| prev [-]
		> what happens if you onboard a superstar that works with django some other way If you hired a "superstar" that goes out of their way to hand-write migrations in cases where Django can do it by default (the majority of them) you did not in fact get a superstar. I have yet to see anyone hand-roll migrations on purpose. In fact the problem is usually the opposite, the built-in migration generator works so well that a lot of people have very little expertise is doing manual migrations because they maybe had to do it like 5 times in their entire career.

▲

3eb7988a1663 a day ago | parent | prev [-]

I 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 a day ago | parent [-]

sounds inconvenient and error-prone

▲

3eb7988a1663 a day ago | parent [-]

It 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 10 hours ago \| parent [-]
		yeah 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.