On Sun, Aug 2, 2009 at 9:24 PM, Russell Keith-Magee<freakboy3...@gmail.com> wrote: > > 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 %-) > > BINGO, you got it. single threaded test server and the admin validation locked it up.
i had just figured it out. a little more testing and i pointed the URL at cnn.com and it worked. thanks for all the workarounds. rusty --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
