Modify

Ticket #273 (closed enhancement: fixed)

Opened 5 years ago

Last modified 3 years ago

Don't pull through default values from models.py

Reported by: andrew Owned by: andrew
Priority: major Milestone: 0.7
Component: commands Version: 0.6.1
Keywords: Cc:

Description

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.

Attachments

Change History

comment:1 Changed 5 years ago by 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.

comment:2 follow-up: ↓ 3 Changed 5 years ago by 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).

comment:3 in reply to: ↑ 2 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

comment:5 Changed 4 years ago by andrew

  • Status changed from new to closed
  • Resolution set to fixed

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

comment:6 Changed 4 years ago by claude@…

Wow, awesome!

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.