*About database agnostic migrations.* Liquibase is a tool which is decoupled from the app layer and gives a possibility to write agnostic changesets. To be independent you must use builtin operations and narrow used field types to "well known" subset <http://www.liquibase.org/documentation/column.html>. Anything else is passed through, same as plain SQLs are passed througd.
So as a DB architect I can decide what is most important to me - portability or db-specific features. This concept may be easily adopted to the Django migrations, because the operations are currently implemented. *About custom fields* Liquibase is extensible. The concept is about extending a "well-know" fields subset by registering extensions. For example - django.contrib.postgres may provide an extension to the migration subsystem by registering new types and new operations. For 3rd party apps there will be requirement to deliver extension to a migration system, not to the project itself. This would be real "game changer". Until the extension is installed, your migrations will work. You may recreate you app from scratch but leave extensions - and your db refactorings will be still safe. *About files separation* Liquibase has the include operation. The similar may be implemented for the Django migrations. The only problem is that the Python code is rather unordered, and some explicit ordering should be introduced. This would be quite irrelevant for Python-based changesets (migration files), but after dropping direct application layer dependency there would be possibility to use other language than Python to describe operations to aplly. *Application layer agnostic migrations* The migrations subsystem must match their field types to the registered one, and render a changeset (migration file) using these registered *names *instead of direct field classes. Anything unmatched must be passed as a CUSTOM type or just passed through by name (may introduce incompatibility, when someone will register a field of the same name in the future). How to mark a custom type requires discussion, of course. *Backward compatibility* You can prevent backward compatibilty by allowing usage of directly imported fields, same as nowdays. In that case the field-mapping layer will be bypassed. *Automatic changes detection* Should work same as nowdays. But I must dig into internals to confirm that. 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 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/dca84944-a35b-47ea-9463-a64ea2c48343%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
