Ticket #923 (closed defect: wontfix)

Opened 4 years ago

Last modified 4 years ago

Autodetector does not detect changing base class of a custom field

Reported by: raf.geens@… Owned by: andrew
Priority: major Milestone:
Component: migrations Version: 0.7.3
Keywords: autodetector Cc: rafgeens@…


I had a bunch of IntegerField? fields that I changed into PostiveIntegerFields?, which the autodetector correctly generated changes for. However, I also had a custom field with an overridden validate method which derived from IntegerField?. When I changed that to PositiveIntegerField?, the autodetector did not see it.

Change History

comment:1 Changed 4 years ago by andrew

  • Status changed from new to infoneeded

How does your custom field get the field triple generated? Does it have a south_field_triple method, or does it have a custom introspection rule?

comment:2 Changed 4 years ago by raf.geens@…

  • Status changed from infoneeded to assigned

Since I derived from a Django field and added no attributes, I followed the advice at http://south.aeracode.org/docs/customfields.html#extending-introspection and added an empty rule:

add_introspection_rules([], ^core\.models\.CustomField?)
class CustomField?(models.PositiveIntegerField?):

def validate(self, value, model_instance):

comment:3 Changed 4 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to wontfix

Alright, this is not really a bug in South, at least not one we can fix under current design patterns - South identifies field types by their full class name, and uses changes in that to detect changes in type.

When you write a custom field and use it in South, you have to make two promises:

  • That the field will always be accessible from its initial import path
  • That the field will not change type or constraints

If you do either of these things, South can't detect what's happened, and so it will just ignore the changes.

I'm closing this WONTFIX for that reason - introspection is built around these two assumptions, and what you did broke one (though since they're not exactly made very obvious, that's fair game). I recommend that you give a new name to your positiveintegerfield-based custom field, and keep the old one around; or, if you're using MySQL or SQLite, just stick with subclassing IntegerField?, as there's no difference between that and Positive... on those backends.

comment:4 Changed 4 years ago by raf.geens@…

Thanks for clarifying, that's very useful to know. I do see a difference on MySQL between IntegerField? and PositiveIntegerField?: besides the Django validation, it makes the integer column unsigned.

comment:5 Changed 4 years ago by andrew

Ah, yes, I stand corrected - usually PositiveIntegerField only comes up with constraints issues!

Note: See TracTickets for help on using tickets.