I've seen a couple of suggestions, including
http://groups.google.com/group/django-users/browse_frm/thread/b8383edb0408e2e9
suggests using a TextField and adding URL validation - a workable way,
but then why bother with a URLField anyway. (and URLField doesn't
actually subclass CharField)
This is somewhat related to the discussion in
http://groups.google.com/group/django-developers/browse_frm/thread/a5239021d241f025
about removing such data types from the backends where possible.
Before I reopen #1477 and suggest a patch, any preferences about what
should be done...
options I can see for URLField are:
1. (minimal chage) make URLField work like SlugField does - code in a
fallback maxlength in the class init in
django.models.fields.__init__.py, and change the backends to have
varchar(%(maxlength)s)
(I don't find that idea very forward-looking though)
2. make URLField like EmailField, as a subclass of CharField, but with
a fallback maxlength like SlugField has. (and of course add a
get_internal_type). Again, we might hit a higher limit, because the
backend might use a field (like varchar) which is limited in length.
Anyone care to add what the varchar limits are for the DBs Django
supports? Anyway, making those fields 'long enough' is really the job
of the backend anyway. I suppose we really should define what is 'long
enough' for each basic field type. For a URLField, whatever it
subclasses should be able to handle 2048 chars, I think.
(I prefer this idea, and it would remove URLField entirely from the
backend DATA_TYPES)
Would either of these break backwards compatibility? Don't see they
do.
Have I missed any relevant development which is changing the way
backends work? I guess this is an area which works well enough that
most people don't need to worry about it. But since #1477 was worthy
of being fixed, I'd like to make a patch to fix it. I'm just trawling
for comments here first.