Changes between Version 155 and Version 156 of BackwardsIncompatibleChanges


Ignore:
Timestamp:
Feb 18, 2008, 9:03:54 PM (17 years ago)
Author:
Malcolm Tredinnick
Comment:

Documented Field.get_internal_type() change

Legend:

Unmodified
Added
Removed
Modified

  • BackwardsIncompatibleChanges

    v155 v156  
    5151 * [7082] Feb 3, 2008 [#Raiseerrorsifextendsisnotthefirsttagofatemplate Raise errors if extends is not the first tag of a template]
    5252 * [7091] Feb 5, 2008 [#Changees_ARtoes-arinLANGUAGES Change es_AR to es-ar in LANGUAGES]
     53 * [7133] Feb 18, 2008 [#ChangedField.get_internal_typedefault Changed Field.get_internal_type() default]
    5354
    5455== Database constraint names changed ==
    … …  
    567568
    568569The only slight consequence here is that the Argentinean Spanish was incorrectly specified as es_AR. If you are using Django's default language list, there is no change required, since the central list has been updated and specifying es-ar as the preference in your browser will still work. However, if you have created a custom LANGUAGES list in your settings file, overriding the list in global_settings, you will need to change "es_AR" to read "es-ar", otherwise your Argentinean Spanish readers will see English text, not Spanish.
     570
     571== Changed Field.get_internal_type() default ==
     572
     573If you were subclassing an existing model field and were relying on the fact that the {{{Field.get_internal_type()}}} method would return your class name by default, you will need to alter your code to explicitly say that (i.e. to return the string you want). It seemed that most subclassing of existing fields (even in Django core) were using the parent's column type, so we've now set things up to exploit that. Thus, inheriting from a {{{CharField}}} results in {{{get_internal_type()}}} returning ''CharField'', etc.
Back to Top