> > > Some of these are problems, yes, but you have to understand they are > tradeoffs and the alternative is, in my opinion, worse. > > Yes, I understand. But maybe there is another / better alternative. Let's simplify a little and talk about a python deps first.
> > I believe that there exist some solution, which drops app layer > dependency ands allow using custom fields > > I would love to see what this would be. I spent a decade trying not to > import custom fields from the code to allow this and never succeeded; the > only way that I could make it work was to import them. Because Django > allows fields to change their type based on the database being talked to, > you can't bake the type into the migration at creation time > The advantages comes from db type independency, this is true, but in the other side you're including the app layer dependency. Let's imagine that one of builtin field will change it's definition. Running migrations on two different Django versions will produce two different outputs. My perspective is more database-like than app-like, so I'm expecting same db schema as a result (for both cases). So the first thing that comes into my mind sounds: a complete definiton should be baked in migration file. Then, when app layer changes (i.e. upgrading framework or changing custom field definition), the migration system should identify the change and produce new migration with baked in definition. If it is possible to develop, you'll achieve less dependencies. The definition (a meta-description of the field) will be baked in, instead of depending on the field itself. And you'll preserve database type independency. This is a just first concept that comes to my mind, now. > Python code in migrations > > This has always been optional; Django's makemigrations will never put in > RunPython for you, so if you choose to use it, then it's your choice and > you get the problems along with it (more tied to application code). > > In that case I'd like to avoid RunPython in Django's contrib apps builtin migrations, not to remove the possibility of running any executable. I'd just like to add comment to it "do it at your own risk" ;) > > Separate files for changesets > > This is needed if you are going to have migrations per-app and thus let > apps ship migrations. If you want to not have per-app migrations, then you > can have just the one file, but then you make third-party apps have to ship > migration snippets you need to remember to include when you make the next > migration. > > Leave it as is for a while. It isn't so important. > Squashing is a just a workaround tool for migrations design issues > > Yes, specifically it is designed to help solve the > custom-fields-app-dependency issue. It's also just nice to have anyway when > you get to 100 migrations. > > The second isn't an issue, in practice. After x years I have thousands of migrations in Liquibase, and the only one downside of this lies in time required to run them all in CI build. But this is automated, so nobody cares about minute or two. > > A discussion about removing app layer dependency and removing or > limiting RunPython usage, mostly. > > OK, so what is your proposed alternative for custom fields? It is no good > to propose to remove something without proposing what to do in its place; > we can't drop custom field support in migrations. > To be precise - I don't want to remove anything and break compatibility. I'd like to improve some things. The (first) proposal is about decoupling migrations from the app layer. I wrote the example few lines above. I don't want to write all possible proposals at this moment, because I suppose that you discussed the topic a very long time. We can focus now on the sepearation of a field definitions, to achieve consistency in time. BR, Marcin -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ed5f17fe-3967-494d-8423-7d0143282ac9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
