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 -~----------~----~----~----~------~----~------~--~---
