EVOLUTION-MANAGER

Edit File: NEWS

version 0.7.7 (25-May-2017):
	* New Features:
		* Added a note about backing up the database and not cancelling before
		  executing an evolution.

The confirmation prompt for executing an evolution now suggests
		  backing up the database first. This is only shown in interactive
		  mode.

After the user has confirmed, they're told it may take time and to
		  not cancel the upgrade.

* Added more output when performing evolutions for apps.

When evolving the database, a message is now outputted to the console
		  for each app being evolved. This gives a sense of progress for
		  larger evolutions.

If the evolution fails, an error message will be shown listing the
		  app that failed evolution, the specific SQL statement that failed,
		  and the database error. This can help when diagnosing and recovering
		  from the problem.

* Added an option for writing hinted evolution files.

There's now a -w/--write option that can be used with
		  evolve --hint that writes the hinted evolution to the appropriate
		  directories in the tree. This takes the name that should be used
		  for the evolution file.

This will not update the evolutions/__init__.py file.

* Bug Fixes:
		* Fixed issues with evolution optimizations when renaming models.

Django Evolution's evolution optimization code had issues when
		  applying a series of evolutions that add a ForeignKey field to a
		  newly-introduced model that is then renamed in the same batch. The
		  resulting field would still point to the original model, resulting in
		  a KeyError.

version 0.7.6 (1-December-2015):
	* Bug Fixes:
		* Fixed a false positive with schema errors when applying evolutions
		  on MySQL.

When applying new evolutions along with baseline schemas for new
		  models, two version history entries are created, one for the new
		  baselines, and one for the new, final schema. On MySQL, this can
		  happen so quickly that they'll end up with the same timestamp (as
		  there isn't a lot of precision in these fields).

Due to internal sort orders, the next evolution then finds the
		  version entry for the baseline schema, and not the final evolved
		  schema, causing it to fail saying that there are changes that
		  couldn't be applied.

This fixes this problem by improving the sorting order.

* Fixed issues evolving certain changes from old database schemas.

Old database schemas didn't track certain information, like the
		  index_together information. The code was previously assuming the
		  existence of this information and failing if it wasn't there.
		  Evolving from these older schemas now works.

version 0.7.5 (13-April-2015):
	* Bug Fixes:
		* Mutations on fields with the same name across different models no
		  longer results in conflicts.

With the new optimizer in 0.7, it was possible for mutations to be
		  incorrectly optimized out if, for example, a field was added in one
		  model and then later changed in another model, if both fields had
		  the same name. This was due to the way in which we mapped mutations,
		  and would result in an error in the validation stage before attempting
		  any database modifications. There are no longer any conflicts between
		  same-named field.

* Indexes are no longer created/deleted unnecessarily.

If setting an index for a field, and it already exists in the
		  database, there's no longer an attempt at creating it. Likewise,
		  there's no longer an attempt at deleting an index that does not
		  exist.

version 0.7.4 (15-September-2014):
	* New Features:
		* Add a RenameModel mutation for handling model renames.

The new RenameModel mutation allows an evolution to indicate that a
		  model has been renamed. This handles updating the signature for any
		  related ForeignKeys or ManyToManyFields and generating any SQL to
		  perform the table rename (if needed).

version 0.7.3 (24-July-2014):
	* Bug Fixes:
		* Fixed issues evolving unique_together attributes on models.

When adding unique_together constraints and then changing them within
		  a single evolve operation, any constraints listed more than once
		  would result in unnecessary duplicate SQL statements. These would
		  cause errors that would prevent the transaction from completing.

* Adding and removing a unique_together constraint within an evolve
		  operation no longer breaks on PostgreSQL.

* Errors importing a database backend on a modern Django no longer
		  results in unrelated errors about settings.DATABASE_ENGINE.

version 0.7.2 (2-June-2014):
	* Bug Fixes:
		* Fixed a crash from no-op column renames on PostgreSQL.

When attempting to rename a column on PostgreSQL and specifying a
		  "new" name that was the same as the old name, the result would
		  be a crash. This is similar to the bug fixed in 0.7.1.

version 0.7.1 (21-May-2014):
	* Bug Fixes:
		* Fixed a crash from no-op column renames on MySQL.

When attempting to rename a column on MySQL and specifying a
		  "new" name that was the same as the old name, the result would
		  be a crash. Likewise, there were crashes when renaming a
		  ManyToManyField.

version 0.7.0 (3-February-2014):
	* New Features:
		* Added compatibility with Django 1.6.

version 0.7.0 beta 1 (14-January-2014):
	* New Features:
		* Added compatibility with Django 1.5. (Bug #136)

* Dropped compatibility for versions of Django prior to 1.4.10.

* Added better support for dealing with indexes in the database.

Django changed how index names were generated over time, leading
		  to issues when evolving old databases. We now scan the database
		  prior to evolution, gather the indexes, and look them up based
		  on field data dynamically, guaranteeing we find the correct
		  index.

It's also more resilient now when using custom indexes placed by
		  an administrator.

* Added support for evolving unique_together and index_together
		  fields.

unique_together was previously stored, but ignored, meaning that
		  changes to a unique_together would not ever apply to an existing
		  database.

index_together, on the other hand, is new in Django 1.5, and
		  was never even stored.

There's now a ChangeMeta mutation that allows for changing
		  unique_together and index_together.

Models making use of unique_together or index_together will
		  have to supply evolutions defining the current, correct values.
		  These will appear when running `evolve --hint`.

* Optimized the SQL before altering the database.

Mutations are now pre-processed and their output post-processed
		  in order to reduce the number of table-altering mutations. This
		  should massively reduce the amount of time it takes to update
		  a database, particularly when there are multiple AddFields,
		  ChangeFields, or DeleteFields on a single table.

This is the biggest change in this release, and while it's been
		  tested on some large sets of mutations, there may be regressions.
		  Please report any issues you find.

Custom field mutation classes will need to be updated to work with
		  these changes.

* Bug Fixes:
		* Fixed a number of issues with constraints on different databases.
		  (Bug #127)

* Fixed an invalid variable reference when loading SQL
		  evolution files. (Bug #121)

* SQL evolution files no longer break if there are blank lines.
		  (Bug #111)

* Booleans are now normalized correctly when saving in the database.
		  (Bug #125)

Previously, invalid boolean values would be used, causing what
		  should have been a "false" value to be "true".

* Usage:
		* The evolve command no longer recommends running
		  `evolve --hint --execute`, which can easily cause unwanted problems.

* Testing:
		* Added easier unit testing for multiple database types.

The ./tests/runtests.py script now takes a database type as an
		  argument. The tests will be run against that type of database.

To make use of this, copy test_db_settings.py.tmpl to
		  test_db_settings.py and fill in the necessary data.

* Fixed all the known unit test failures.

* Rewrote the test suite for better reporting and maintainability.

* Packaging:
		* Fixed the unit tests module being accidentally bundled with the
		  package. (Bug #134)

* Fixed the missing NEWS file in the releases. (Bug #130)

version 0.6.9 (13-March-2013):
	* Django Evolution no longer applies upgrades that match the current state.

When upgrading an old database, where a new model has been introduced
	  and evolutions were added on that model, Django Evolution would try to
	  apply the mutations after creating that baseline, resulting in
	  confusing errors.

Now we only apply mutations for parts of the database that differ
	  between the last stored signature and the new signature. It should
	  fix a number of problems people have hit when upgrading extremely
	  old databases.

version 0.6.8 (8-February-2013):
	* Added two new management commands: list-evolutions and wipe-evolution.

list-evolutions lists all applied evolutions. It can take one or more
	  app labels, and will restrict the output to those apps.

wipe-evolution will wipe one or more evolutions from the database. This
	  should only be used if absolutely necessary, and can cause problems. It
	  is useful if there's some previously applied evolutions getting in the
	  way, which can happen if a person is uncareful with downgrading and
	  upgrading again.

version 0.6.7 (12-April-2012):
	* Don't fail when an app doesn't contain any models.

Installing a baseline for apps without models was failing. The code to
	  install a baseline evolution assumed that all installed apps would
	  have models defined, but this wasn't always true. We now handle this
	  case and just skip over such apps.

version 0.6.6 (1-April-2012):
	* Generate more accurate sample evolutions.

The sample evolutions generated with --hint should now properly
	  take into account import paths for third-party database modules.
	  Prior to this, such an evolution had to be modified by hand to
	  work.

* Generate PEP-8-compliant sample evolutions.

The evolutions are now generated according to the standards of
	  PEP-8. This mainly influences blank lines around imports and the
	  grouping of imports.

* Support Django 1.4's timezone awareness in the Version model.

The Version model was generating runtime warnings when creating an
	  instance of the Version model under Django 1.4, due to using
	  a naive (non-timezone-aware) datetime. We now try to use Django's
	  functionality for this, and fall back on the older methods for
	  older versions of Django.

version 0.6.5 (15-August-2011):
	* Fixed the version association for baseline evolutions for apps.

The new code for installing a baseline evolution for new apps in 0.6.4
	  was associating the wrong Version model with the Evolution. This doesn't
	  appear to cause any real-world problems, but it does make it harder
	  to see the proper evolution history in the database.

* Added a built-in evolution to remove the Message model in Django 1.4 SVN.

Django 1.4 SVN removes the Message model from django.contrib.auth.
	  This would break evolutions, since there wasn't an evolution for this.
	  We now install one if we detect that the Message model is gone.

version 0.6.4 (22-June-2011):
	* Install a baseline evolution history for any new apps.

When upgrading an older database using Django Evolution when a new model
	  has been added and subsequent evolutions were made on that model, the
	  upgrade would fail. It would attempt to apply those evolutions on that
	  model, which, being newly created, would already have those new field
	  changes.

Now, like with an initial database, we install a baseline evolution
	  history for any new apps. This will ensure that those evolutions aren't
	  applied to the models in that app.

* Fixed compatibility with Django SVN in the unit tests.

In Django SVN r16053, get_model() and get_models() only return installed
	  modules by default. This is calculated in part by a new
	  AppCache.app_labels dictionary, along with an existing
	  AppCache.app_store, neither of which we properly populated.

We now set both of these (though, app_labels only on versions of Django
	  that have it). This allows the unit tests to pass, both with older
	  versions of Django and Django SVN.

version 0.6.3 (9-May-2011):
	* Fixed multi-database support with different database backends.

The multi-database support only worked when the database backends
	  matched. Now it should work with different types. The unit tests have
	  been verified to work now with different types of databases.

* Fixed a breaking with PostgreSQL when adding non-null columns with
	  default values. (Bugs #58 and #74)

Adding new columns that are non-null and have a default value would
	  break with PostgreSQL when the table otherwise had data in it. The
	  SQL for adding a column is an ALTER TABLE followed by an UPDATE to set
	  all existing records to have the new default value. PostgreSQL, however,
	  doesn't allow this within the same transaction.

Now we use two ALTER TABLEs. The first adds the column with a default
	  value, which should affect existing records. The second drops the
	  default. This should ensure that the tables have the data we expect
	  while at the same time keeping the field attributes the same as what
	  Django would generate.

version 0.6.2 (19-November-2010):
    * Add compatibility with Django 1.3.

Django 1.3 introduced a change to the Session.expire_date field's
      schema, setting db_index to True. This caused Django Evolution to
      fail during evolution, with no way to provide an evolution file to
      work around the problem. Django Evolution now handles this by providing
      the evolution when running with Django 1.3 or higher.

version 0.6.1 (25-October-2010):
    * Fixed compatibility problems with both Django 1.1 and Python 2.4.

version 0.6.0 (24-October-2010):
    * Added support for Django 1.2's ability to use multiple databases.

This should use the existing routers used in your project. By default,
      operations will happen on the 'default' database. This can be overridden
      during evolution by passing --database=dbname to the evolve command.

Patch by Marc Bee and myself.

version 0.5.1 (13-October-2010):
    * Made the evolve management command raise CommandError instead of
      sys.exit on failure. This makes it callable from third party software.
      Patch by Mike Conley.

* Made the evolve functionality available through an evolve() function
      in the management command, allowing the rest of the command-specific
      logic to be skipped (such as console output and prompting). Patch
      by Mike Conley.

* Fixed incorrect defaults on SQLite when adding null fields. (Bug #49)

On SQLite, adding a null field without a default value would cause the
      field name to be the default. This was due to attempting to select the
      field name from the temporary table, but since the table didn't exist,
      the field name itself was being used as the value.

We are now more explicit about the fields being selected and populated.
      We have two lists, and no longer assume both are identical. We also use
      NULL columns for temporary table fields unconditionally.

Patch by myself and Chris Beaven.

version 0.5.0 (18-May-2010):
    * Initial public release