Opened 8 years ago

Closed 8 years ago

Last modified 5 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: master
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:

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 8 years ago.
8210-2.diff (8.2 KB) - added by Matt McClanahan 8 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 8 years ago by Julian Bez

Triage Stage: UnreviewedAccepted

comment:2 Changed 8 years ago by Jakub Wilk <ubanus@…>

Cc: ubanus@… added

comment:3 Changed 8 years ago by Russell Keith-Magee

milestone: 1.0
Triage Stage: AcceptedDesign decision needed

comment:4 Changed 8 years ago by Russell Keith-Magee

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 Changed 8 years ago by Jacob

Component: Core frameworkDatabase wrapper
Triage Stage: Design decision neededAccepted

comment:6 Changed 8 years ago by Matt McClanahan

Owner: changed from nobody to Matt McClanahan
Status: newassigned

Changed 8 years ago by Matt McClanahan

Attachment: 8210-1.diff added

comment:7 Changed 8 years ago by Matt McClanahan

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.

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

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.

comment:9 in reply to:  7 Changed 8 years ago by Jacob

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.

Changed 8 years ago by Matt McClanahan

Attachment: 8210-2.diff added

comment:10 Changed 8 years ago by Jacob

Owner: changed from nobody to Jacob
Status: newassigned

comment:11 Changed 8 years ago by Jacob

Resolution: fixed
Status: assignedclosed

Fixed in [8819].

comment:12 Changed 6 years ago by ubanus@…

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

comment:13 Changed 5 years ago by Jacob

milestone: 1.0

Milestone 1.0 deleted

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