Code

Opened 7 years ago

Closed 7 years ago

#5342 closed (fixed)

EmailField dbfield should accept max_length parameter

Reported by: gwilson Owned by: donspaulding
Component: Core (Other) Version: master
Severity: Keywords: sprintsept14
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

EmailField is currently hard-coded to a max length of 75.

Discussion: http://groups.google.com/group/django-developers/browse_frm/thread/662aa47cb546a20/

Attachments (1)

new_emailfield.diff (981 bytes) - added by donspaulding 7 years ago.
Added the similarly easy documentation change.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Accepted based on comments to the above thread.

comment:2 Changed 7 years ago by donspaulding

  • Has patch set

comment:3 follow-up: Changed 7 years ago by deepak <deep.thukral@…>

  • Patch needs improvement set

IMO, it shouldn't it be more than 255(max varchar) characters in anycase or hard-coded 255 is fine, why it should be configurable?

comment:4 in reply to: ↑ 3 Changed 7 years ago by donspaulding

  • Owner changed from nobody to donspaulding
  • Status changed from new to assigned

Replying to deepak <deep.thukral@gmail.com>:

IMO, it shouldn't it be more than 255(max varchar) characters in anycase or hard-coded 255 is fine, why it should be configurable?

The current standard for email is that the maximum *guaranteed* email address length be 320 chars (64 chars for username, 255 for domain, 1 for '@') [1]. However, to the extent possible, SMTP servers should not limit the size of email addresses. Realizing Django isn't an email server framework, having it provide a reasonable default (75 is arbitrary but backwards compatible) isn't ridiculous, but this patch should let users override the default. Any further discussion should probably be brought back up on the dev mailing list.

[1] - RFC2821 - pages 53-54

comment:5 Changed 7 years ago by deepak <deep.thukral@…>

  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

Yes, I am aware of RFC2821, but didnt know about SMTP server no size limits, apologies.

comment:6 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Ready for checkin to Design decision needed

The consensus from on the django-dev thread was at least two maintainers were against making it configurable. So I don't there's enough consensus here yet that it's ready-for-checkin. There are some arguments for making it configurable and similar ones against, but we should go through the process.

Changed 7 years ago by donspaulding

Added the similarly easy documentation change.

comment:7 Changed 7 years ago by adrian

  • Triage Stage changed from Design decision needed to Accepted

Let's do this -- it's clear, obvious and backwards compatible.

comment:8 Changed 7 years ago by donspaulding

  • Triage Stage changed from Accepted to Ready for checkin

comment:9 Changed 7 years ago by Fredrik Lundh <fredrik@…>

  • Keywords sprintsept14 added

comment:10 Changed 7 years ago by adrian

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [6205]) Fixed #5342 -- Added max_length parameter to EmailField. Thanks, donspaulding and gwilson

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.