Modify

Ticket #41 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Handling of fields in startmigration creates problematic code dependencies

Reported by: agkish@… Owned by: andrew
Priority: major Milestone: 0.5
Component: commands Version: 0.3
Keywords: Cc:

Description

By default startmigration just copies fields making create_table input such as:

('status', models.CharField(max_length=1, choices=TradeStatus, default='B')),

If TradeStatus? is removed in later code, when someone tries to create a database from scratch or migrate back to the original version South will crash because it can't find TradeStatus?. Because options like choices do not affect the schema (I think) and only matter at app runtime, they should be omitted, and the generated code would look like this instead:

('status', models.CharField(max_length=1)),

I've looked into writing a patch for this, but not only can I not figure out how to introspect and determine if a field option will affect the schema—I can't even find any documentation on what options do affect the schema! If you know of any such docs, it'd help me immensely in writing a patch.

Attachments

Change History

comment:1 Changed 5 years ago by andrew

  • Status changed from new to assigned

Yes, we've had great fun with the "nick-fields-from-models.py" code. At the moment, it's just a simple string parser...

But, back to the ticket. There's no document that says which options affect the schema or not, but it's reasonably easy to guess, delve into the ORM code to look (I've done that a lot recently) or, at the very worst, change it and see if the database schema changes.

We were planning to implement some kind of near-decent parser for the field definitions in models.py (perhaps using the python parser module, although it produces very verbose output), but if you can think of a better solution, I'd love to hear it.

comment:2 Changed 5 years ago by andrew

  • Status changed from assigned to accepted
  • Version set to 0.3
  • Milestone set to The Future

This, #45 and #47 all look like we're going to need a real parser. Assigning to The Future.

comment:3 Changed 5 years ago by andrew

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

Fixed by the ORM Freezer checkin, committed in [140] - [143] (the new startmigration(2) removes choices as a keyword).

comment:4 Changed 5 years ago by andrew

  • Milestone changed from The Future to 0.5
View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


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

 
Note: See TracTickets for help on using tickets.