On Thu, May 15, 2008 at 6:45 AM, James Bennett <[EMAIL PROTECTED]> wrote: > On Thu, May 15, 2008 at 5:34 AM, Amit Ramon <[EMAIL PROTECTED]> wrote: >> Was there any change in django in the recent months that could explain this? >> Namely, could it be that a couple of months ago django would indeed generate >> a varchar(20) for this field, and now it generates int(11)? > > I'll bet money that at the time the table was created you were using > Django's built-in PhoneNumberField, which is specified as VARCHAR(20): > > http://code.djangoproject.com/browser/django/trunk/django/db/backends/mysql/creation.py#L21
Actually, it wouldn't have mattered if it was Django's own PhoneNumberField or not. Prior to [7133] (Feb 18, 2008), Django used the name of the field class to determine which entry in creation.py to use, regardless of what they inherited from. After that revision, however, fields that specify a get_internal_type() will always use that value for all their subclasses, regardless of what they're named, unless they override it. This was in fact detailed on the backwards-incompatible changes page,[1] as would be expected. You have two options. Just provide your own get_internal_type() to return "PhoneNumberField" or, better yet, just inherit from Django's PhoneNumberField. You'll probably get better stuff that way, anyway. -Gul [1] http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#ChangedField.get_internal_typedefault --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
