Completely redo the way we install baselines after syncdb/migrate.

Review Request #10581 — Created June 7, 2019 and submitted

Information

Django Evolution
master

Reviewers

Historically, Django Evolution would set up its baselines (Version and
Evolution entries) in response to a syncdb (and, in recent
development, migrate). Along with this, it would output messages saying
which apps needed to be evolved, and which baselines were being
installed. This was designed in part to help provide instructions, since
evolve had to be run alongside syncdb, and the order mattered.

With the introduction of the Evolver, the entire process is designed
to be done in one command (evolve --execute). There's no longer a need
to output any hints or to diff any signatures. The generation of
baselines can also be streamlined, and database writes optimized,
massively reducing unit test runs.

Further, we no longer need or want to do this every time we react to
this signal. If an Evolver.evolve() operation is running, then
baselines are already being managed, and there's no point in doing
anything at all. Instead, we only need to do this when we get these
signals outside of the Evolver (such as during unit tests or database
flushes).

Unit tests pass on all supported versions of Django.

Summary ID
Completely redo the way we install baselines after syncdb/migrate.
Historically, Django Evolution would set up its baselines (`Version` and `Evolution` entries) in response to a syncdb (and, in recent development, migrate). Along with this, it would output messages saying which apps needed to be evolved, and which baselines were being installed. This was designed in part to help provide instructions, since `evolve` had to be run alongside `syncdb`, and the order mattered. With the introduction of the `Evolver`, the entire process is designed to be done in one command (`evolve --execute`). There's no longer a need to output any hints or to diff any signatures. The generation of baselines can also be streamlined, and database writes optimized, massively reducing unit test runs. Further, we no longer need or want to do this every time we react to this signal. If an `Evolver.evolve()` operation is running, then baselines are already being managed, and there's no point in doing anything at all. Instead, we only need to do this when we get these signals outside of the `Evolver` (such as during unit tests or database flushes).
8c3b7340125b6b8f5a57daf5057336a22cd6681a
Description From Last Updated

E302 expected 2 blank lines, found 1

reviewbotreviewbot
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (01e1f75)
Loading...