My favorites | Sign in
Project Home Wiki Issues
Checkout   Browse   Changes  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
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

Change log

r225 by chipx86 on Mar 13, 2013   Diff
Release Django Evolution 0.6.9.
Go to: 

Older revisions

r222 by chipx86 on Feb 8, 2013   Diff
Release Django Evolution 0.6.8.
r219 by chipx86 on Apr 12, 2012   Diff
Release Django Evolution 0.6.7.
r216 by chipx86 on Apr 1, 2012   Diff
Release Django Evolution 0.6.6.
All revisions of this file

File info

Size: 7208 bytes, 171 lines
Powered by Google Project Hosting