Django

Code

Ticket #6556 (closed: fixed)

Opened 7 months ago

Last modified 6 months ago

Custom subclass of models.CharField does not appear in the CREATE SQL

Reported by: jarrow Assigned to: nobody
Milestone: Component: Database wrapper
Version: SVN Keywords:
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

If I subclass models.CharField? (without overwriting anything) it seems to work perfectly but the field is not created on syncdb anymore. Explicitly defining get_internal_type() fixes this.

That's the field (working)

class Event(models.Model):
    urania_event_id = models.CharField("foo", max_length=4, unique_for_year="time")

Subclassed without changing anything.

class UraniaEventID(models.CharField):
    pass
    
class Event(models.Model):
    urania_event_id = UraniaEventID("foo", max_length=4, unique_for_year="time")

Effect: 'urania_event_id' does not appear in CREATE SQL anymore

Workaround:

class UraniaEventID(models.CharField):
    def get_internal_type(self):
        return "CharField"

class Event(models.Model):
    urania_event_id = UraniaEventID("foo", max_length=4, unique_for_year="time")

Attachments

Change History

02/06/08 16:58:13 changed by brosner

  • needs_better_patch changed.
  • version changed from newforms-admin to SVN.
  • needs_tests changed.
  • needs_docs changed.

Whether or not this is a problem, I highly doubt this is specific to newforms-admin as it has NOTHING to do with the database wrapper. Please verify this is the case on SVN, regardless if this is an actual problem or not. If I am wrong, please do correct me, but with some solid evidence :)

02/06/08 17:19:47 changed by jarrow

Ok. Confirmed on SVN r7092. Still the same. I just thought I'll tell the truth that it wasn't tested on trunk :)

02/07/08 01:37:58 changed by mackenzie

I can also confirm this.

Also thanks for the workaround!!!

02/18/08 20:58:41 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [7133]) It makes sense that when you subclass an existing model field, you're often going to be using the same database column type. Made that properly inheritable (previously it was using the class name), at the cost of a little more verboseness.

This is very slightly backwards incompatible (for subclasses of existing fields that were relying on the old default).

Fixed #6556.


Add/Change #6556 (Custom subclass of models.CharField does not appear in the CREATE SQL)




Change Properties
Action