Add a concept of "mutators" to the evolution process.

Review Request #5174 — Created Dec. 29, 2013 and submitted — Latest diff uploaded

Information

Django Evolution
master

Reviewers

Add a concept of "mutators" to the evolution process.

Mutations (AddField, etc.) were previously responsible for talking
directly to the database-specific evolution operations backends in order
to generate SQL. While this worked, it was limiting, and caused
inefficient SQL.

Django Evolution's generated SQL would generate essentially one
statement per type of operation. A group of AddFields/ChangeFields would
generate an ALTER TABLE for each field, even when operating on the same
table. This would trigger a full rebuild of the table for each field,
which is extremely inefficient.

This change introduces a new design. The mutation classes now talk to
new mutator classes and now register generic operation data, instead of
generating and returning SQL. When the caller is ready to request the
SQL, the mutators will pass their list of pending operations to the
evolution operations backend, which will then determine how to handle
the operations and return SQL.

There are two types of mutators: AppMutator, and ModelMutator. Callers
will instantiate an AppMutator and tell it to run a list of mutations.
AppMutator will do the work of finding batchable mutations to a model
and construct ModelMutators. Both mutators will also work with the
mutations to mutate or simulate when appropriate.

Right now, there are no differences in the resulting SQL. This just sets
the stage for future working. The next cahnge in this series will be
able to take advantage of the operations to better optimize the
resulting SQL to batch operations to models.

Ran unit tests for SQLite3, MySQL and PostgreSQL with Django 1.4 and 1.5.

Compared SQL for an upgrade from RB 1.7 to 2.0 on MySQL, and also performed
an evolution, without problems.

    Loading...