Don't pull through default values from models.py

[andrew]

Defaults are applied by Django anyway - there's no need to drag them through to the DBMS unless they're needed for a NOT NULL column, and even then doing it automatically results in issues with datetime.datetime.now() and friends.

See my comments on #250 - need to remove them from the freezing, and prompt if some value is needed.

[anonymous]

I'd even consider it a bug. Whenever I run {{{manage.py startmigration appname --auto}}, South lists all ORM properties with {{default=datetime.datetime.utcnow}} that I have in my app.
Other that than, {{--auto}} works very smoothly.

[hickswright@…]

I would say that the current behavior for callable defaults is wrong. South should not evaluate them and add them to the database, they're callable for a reason. Values, however, should still be pulled in. Better to have the database do defaults when they're static than force Django to.

In the case of datetime.[utc]now, I would really like to see South recognize it similarly to auto_now_add and give the field the appropriate default in the database (e.g. NOW() or UTC_TIMESTAMP() for mysql).

[andrew]

Replying to hickswright@…:

I would say that the current behavior for callable defaults is wrong. South should not evaluate them and add them to the database, they're callable for a reason. Values, however, should still be pulled in. Better to have the database do defaults when they're static than force Django to.

In the case of datetime.[utc]now, I would really like to see South recognize it similarly to auto_now_add and give the field the appropriate default in the database (e.g. NOW() or UTC_TIMESTAMP() for mysql).

No, my decision here is that defaults will not touch South at all, except under the situation where you're adding a NOT NULL column, where we'll try and get the default, call the callable if there is one, and if we can't get a result ask you for a default value.

Django handles defaults just fine, and I'm very wary of extending and adding things like NOW() behind its back, especially as they'll probably never get used.

[claude@…]

Same problem for me, as I have a default wich gets a random generated hash value. Currently, south generates for each of such field a db.alter_column in each migration.

[andrew]

This is now implemented in 0.7 - defaults are used if needed, and prompted for intelligently.

[claude@…]

Wow, awesome!