Missing to_python methods causing issues with serialization

[Andrew Badr]

Lack of to_python on IntegerField? is breaking our tests that read from XML fixtures.

From what I can tell, this how things are supposed to work: (1) an IntegerField is read in as unicode (from the XML fixture), (2) the row is saved to the database, and (3) field is an integer on the next read from db. However, on one model, we have a post-save signal handler that expects the field to be an integer. This handler throws an exception when it gets unicode, so our tests break.

Is accepting strings a part of the database interface definition? I'm guessing we'd hit this same problem if using a form.

[Malcolm Tredinnick]

The database backends only know about "%s" format markers, so integers and strings are treated similarly at that low-level. Thus, models can happily have strings assigned to integer fields and they'll be stored correctly.

However, I suspect we should be storing proper integers when we can, in the light of no model-aware cleaning and validation in 1.0. Since to_python() is only called at save time, it's not that costly. I'm +0 on considering this a bug, but it's borderline as to the priority. Making 1.0-maybe for that reason.

[Russell Keith-Magee]

(In [8515]) Fixed #8298: Added a to_python method for integer fields. This ensures that the data from deserialized instances is of correct type prior to saving. Thanks to Andrew Badr for the report.

[Jacob]

Milestone 1.0 deleted