Opened 16 years ago

Closed 16 years ago

Last modified 13 years ago

#8210 closed Uncategorized (fixed)

USStateField should be moved to django.contrib.localflavor.us

Reported by: Piotr Lewandowski <django@…> Owned by: Jacob
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

USStateField is currently in django.db.models.fields. Pre-1.0 stage is the last chance to move it to a proper place, i.e. to django.contrib.localflavor.us.

Attachments (2)

8210-1.diff (6.0 KB ) - added by Matt McClanahan 16 years ago.
8210-2.diff (8.2 KB ) - added by Matt McClanahan 16 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by Julian Bez, 16 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Jakub Wilk <ubanus@…>, 16 years ago

Cc: ubanus@… added

comment:3 by Russell Keith-Magee, 16 years ago

milestone: 1.0
Triage Stage: AcceptedDesign decision needed

comment:4 by Russell Keith-Magee, 16 years ago

For the record - I'm in favor of this change; It's probably also worth looking at PhoneNumberField (either moving to USPhoneNumberField in localflavor, or reassessing the default widget)

comment:5 by Jacob, 16 years ago

Component: Core frameworkDatabase wrapper
Triage Stage: Design decision neededAccepted

comment:6 by Matt McClanahan, 16 years ago

Owner: changed from nobody to Matt McClanahan
Status: newassigned

by Matt McClanahan, 16 years ago

Attachment: 8210-1.diff added

comment:7 by Matt McClanahan, 16 years ago

Has patch: set
Owner: changed from Matt McClanahan to nobody
Status: assignednew

Some decisions I didn't make:

  • The Person model in docs/topics/db/models.txt uses a models.USStateField. Leaving it in the example without an import line may cause confusion, but it feels wrong to have the import in a code fragment of that sort.
  • db.backends.*.creation defines a [var]char field for USStateField. Should this now be handled by the field itself via db_type, and the entry removed from the creation modules?
  • gis.utils.layermapping maps a USStateField, but may not care about it after the field is no longer in the default django.db.models.fields collection.

in reply to:  4 comment:8 by Piotr Lewandowski <django@…>, 16 years ago

Replying to russellm:

It's probably also worth looking at PhoneNumberField (either moving to USPhoneNumberField in localflavor, or reassessing the default widget)

Thanks for the good remark - I've opened #8664 for this case.

in reply to:  7 comment:9 by Jacob, 16 years ago

Replying to mattmcc:

Some decisions I didn't make:

  • The Person model in docs/topics/db/models.txt uses a models.USStateField. Leaving it in the example without an import line may cause confusion, but it feels wrong to have the import in a code fragment of that sort.

Please add a fix for this in the patch; just throw the import at the top of the code snippet.

  • db.backends.*.creation defines a [var]char field for USStateField. Should this now be handled by the field itself via db_type, and the entry removed from the creation modules?

Yes; please add it to the patch.

  • gis.utils.layermapping maps a USStateField, but may not care about it after the field is no longer in the default django.db.models.fields collection.

It's fine to leave this alone; Justin can clean it up if it bugs him.

by Matt McClanahan, 16 years ago

Attachment: 8210-2.diff added

comment:10 by Jacob, 16 years ago

Owner: changed from nobody to Jacob
Status: newassigned

comment:11 by Jacob, 16 years ago

Resolution: fixed
Status: assignedclosed

Fixed in [8819].

comment:12 by ubanus@…, 14 years ago

Cc: ubanus@… removed
Easy pickings: unset
Severity: Normal
Type: Uncategorized

comment:13 by Jacob, 13 years ago

milestone: 1.0

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top