> > > > 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. >
How do you propose to identify "when the app layer changes"? This is a harder problem to solve that it first appears; the only thing you can rely on to compare to are the migration files themselves, so that necessarily means you need some description of the app layer in there. > > 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" ;) > > It's only in one migration ( https://github.com/django/django/blob/master/django/contrib/contenttypes/migrations/0002_remove_content_type_name.py), and this is because ContentTypes are something that are not purely database-specific. I personally don't like contenttypes anyway, so I would be a fan of making the whole thing vanish into the night, but that's not my call and it would have backwards-compat issues. > 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. > I am impressed that your thousands of migrations only take a few minutes to run; you must have a decent database backing it. Some backends are much slower than this. Squash is offered as an option, and not required; and some people don't even squash and just reset their migrations back to 0001. > > 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. > > Understand when I say that what you are proposing is a very, very big change. Django's ORM is heavily coupled to runtime information and the app layer, and I tried for many years to decouple them and ran into all sorts of issues as a result. Importing the fields from the source code ended up being the easiest, safest method that also happens to produce very easy-to-understand errors when it breaks (rather than using old definitions or silently failing). I am all for migration improvements, but the overall shape of what you are suggesting seems like changing a few fundamental principles of how migrations are designed and essentially designing one of the other types of system (like django-evolution, or dmigrations). If you want a different kind of system, then you are more than welcome to develop one; Django migrations are very deliberately kept separate from the schema-changing backends (SchemaEditor), so it's easier to write custom migration solutions without having to redo all of the nasty per-database code and SQL generation. However, proposing to change the core of the way Django works is going to come with a very high bar and me and others are going to want to see concrete proof of backwards-compatability, improvements to developer experience, and a person or people who are willing to put in all the work to make and land the patch. Personally, I would probably ask that a proposed alternate system was developed as a separate library to prove the concept first (re-using all the bits of Django it needs to, like SchemaEditor and some of the operations code) Andrew -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/CAFwN1uov0okRohsnvigD7T6GcdQMN9AmW16V8Ubv5Cw4v%2BHR6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
