On Mon, Aug 3, 2009 at 12:01 PM, Rusty Greer<gr...@greer.org> wrote:
>
> i added a column to one of my tables in my db.  i added the column in
> the model definition, then i went into mysql and added the column with
> what i think is the appropriate alter table command.
> the command i used was:
>  alter table db_game add column player_info_url varchar(200) not null;
>
> the code in the model is this:
>    player_info_url = models.URLField(blank=True)
>
> i am now able to update that table no problem from mysql.  the new
> field shows up just fine in the admin.  i can edit other tables via
> the admin, however, if i change the table i modified in the admin (not
> just the new field), the development server seems to lock up.  after i
> restart it, all is fine until i edit that same table again.

I'm going to guess that the URL you are storing in player_info_url is
being served by your development server.

If this is the case, you are hitting the limitations of the
single-threaded development server. By default, URLFields validate
that the URL they store is alive (i.e. returns a HTTP 200). This
requires opening a connection to the server to establish the status
code of the request. However, the development server is single
threaded, and is already serving the admin page - which means that the
inner validation request can't be served.

There are at least four possible solutions here.

1. Test using a multi-threaded server - either a full blown
apache/mod_wsgi deployment, or a lightweight fcgi container.

2. Disable validation on the URLField. If you set set
validation=False, Django won't try to validate the URL, so you won't
get the inner request that causes the lockup. You can do this either
as a temporary thing during testing, or as a permanent change,
depending you your needs.

3. Don't use self-links for testing purposes. If you need to use self
links, then you get 'multithreaded lite' by running two instances of
the dev server - one on port 8000 and one on port 8001; use 8001 to
run your tests, but submit URLs from port 8000. Again, depending on
your usage, this could be fiddly, but it is a relatively simple way
around the problem.

4. Close your eyes, hold your nose, and think of England :-) This
problem won't exist on the production server - it's an artefact of the
development server.

Yours
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to