0

Could you tell me why Django hardcodes the business logic into migrations?

We can formulate the question the other way. Let's have a look at valitadors and upload_to. These all is hardcoded into migrations.

But if we show SQL that a migration produces, no validators or upload_to will be there.

So, why are they hardcoded? Validators and upload_to are already mentioned in models. DRY principle is violated.

Any change in the code ruins migrations. For example renaming of upload_to will result in the project's blowing up.

Validators and upload_to are just examples. There are more things of the kind. Anyway, they don't influence the database. So, why do we need them in migrations?

Could you comment?

Kifsif
  • 3,477
  • 10
  • 36
  • 45
  • *"For example renaming of upload_to will result in the project's blowing up."* — How exactly…? – deceze Oct 12 '22 at 14:10
  • @deceze, for example, on migratin_001 it was named "upload_to", but you have renamed it "save_path". You makemigrations, and get an error message: where is "upload_to"? You will have to rename every "upload_to" to "save_path" in all the migrations. – Kifsif Oct 12 '22 at 14:16
  • It would help if you provided the actual verbatim error message, not your paraphrasing of it. – deceze Oct 12 '22 at 14:17
  • @deceze the questoin is not about that. The question is that migrations contain extra information that does not influence the database. You can open your own project and have a look at migrations and SQL requests they produce. You will notice the difference for sure. – Kifsif Oct 12 '22 at 14:20
  • I know how migrations work; in general they do contain a bunch of extraneous information, yes, but those usually don't produce any errors when models are being changed… – deceze Oct 12 '22 at 14:22
  • @deceze, the question is not about errors. The question is: why something is hardcoded there, that doesn't influence the database? – Kifsif Oct 12 '22 at 14:27
  • Basically the model classes are more or less dumped as they are *at that time* into migrations, and the migration system then translates that to SQL statements and diffs between each version. This is just my guess, but it's probably easiest to dump models without much filtering, and let the migration system figure it out later based on the database backend and other factors. — My point is, **that's not usually a problem.** You seem to be asking this because *you* think it's a problem. So we should talk about the perceived problem in detail here… – deceze Oct 12 '22 at 14:33
  • @deceze, it is not a problem. Have I said that it is a problem? I just want to understand Django deeper. You don't need that. It is perfectly Ok. But I am curious. – Kifsif Oct 12 '22 at 14:38
  • After reading this article, I got curious just like you. However, it was not easy to know the design intent of the `migration`. Similar information is https://stackoverflow.com/questions/26503826/why-does-django-make-migrations-for-help-text-and-verbose-name-changes. – gypark Oct 12 '22 at 18:10

0 Answers0