Comment by ralmidani | Hacker News Reader

Comment by ralmidani | Hacker News Reader

Parent Full thread

Django’s approach is to run all the migrations, from the migration files, if the database gets wiped clean. In other words, if you’re developing on your local machine, you can just drop the DB and start new (or if using SQLite, just delete a file), and after running migrations, you never have to worry about whether all the necessary files are in sync with the database. As Neo might say:“there is no spoon…” seriously, structure.sql is simply not needed, so you won’t find yourself making creative use of git reset/checkout on a specific file as you’re iterating.

To answer an earlier question you had, Django’s “makemigrations” command tries its best to help you avoid having to manually edit migration files; if you rename a field in models.py, it’s usually smart enough to ask you, at the command line, if you renamed it, and proceed to make the migration file for you. Of course, for advanced migrations the command can only take you so far, but again, if you’re trying to iterate quickly, you really need to experience Django’s ORM and DB tools to be able to appreciate them fully.

Regarding changesets, I love the functional API, and at the same time I wish we could automatically derive a “default_changeset” function from the schema itself for straightforward cases, and then let devs run diverging validations in their own changeset functions. Maybe an interesting idea to explore with a macro?

By the way, I’m a huge fan of your work, and hope I get the opportunity to work with Elixir for a long time. Any criticisms or comparisons are to try to bring improvements to the ecosystem I love. :)

Thanks! FWIW, structure.sql is not needed in Ecto either. You must do that when:

1. You want to start discarding migrations (because you have too many) 2. You had an existing database

Are those never a "trigger" on Django side? I appreciate the opportunity to learn!

Generally speaking, it's inadvisable to 'discard' migrations with django. If the migration set is getting too large, the general practice is to 'squash' migrations, which is a django-supported function for merging the migrations down to a single app. You can do the less blessed, but more simple function of nuking the migrations, updating the migrations table, and remaking your migrations... but you have to coordinate that in every environment.

For an existing database, you can easily create django models for each table, etc. There's a --fake option to update the migration table to make it think you've applied these migrations, but not actually apply them. This convinces django you've brought the database in sync. May your deity or deities help you if you did not actually bring it in sync. I've used this quite a bit in some java ee->python migrations I've done in the past.

TIL you actually don’t need structure.sql for Ecto! In that case, discarding migrations on a large running app seems like a not-always-good practice, right? FWIW, my experience with Ecto has always been in joining existing codebases that are already big.

I do also want to add that Django can kind of do the reverse of auto-generating migrations: it can “inspect” an existing database and generate Python classes that allow you to use the Django API as if you wrote those classes yourself: https://docs.djangoproject.com/en/4.1/howto/legacy-databases...

Of course, the feature is not going to be perfect, especially if a team has been using odd naming conventions in the legacy database, but it seems helpful at least in theory.

Inspecting a database and coming up with models is a frequent pain point that I see new elixir devs experiencing. I’d love to see someone take a stab at generators for that. I wonder if someone would do an integration for https://ash-hq.org/ that does that.

Reply on news.ycombinator.com