Malcom, Thanks for the well-explained response. It's a bit more complicated than that though as this is only an issue if the field uses a UNIQUE index. It is an issue up through the latest and greatest stable MySQL (tested on 5.0.45 and no bug fixes at MySQL up through 5.0.67) and "./ manage.py validate" triggers 0 errors with a model using CharText(255+) and UNIQUE and using the mysql database type.
As an aside, are most people using Postgres? Should I switch to that for the best tested database for Django? Thanks, Adam On Oct 16, 7:09 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2008-10-16 at 15:28 -0700, adamiis111 wrote: > > I opened up a ticket regarding a bug in the django-app-plugin with > > regards to the indexed CharField being too large > > for MySQL 5.0: > > >http://code.google.com/p/django-app-plugins/issues/detail?id=11 > > > I think that maybe Django's handling of this should be examined more > > generally for one of the following options. > > > 1) Django should disallow CharFields max-length>255. > > For MySQL versions prior to 5.0.3, Django will raise a validation error > (when you run "manage.py validate") when you have a CharField with a > max_length > 255. That's been in place for about two years. > > There's a problem with external apps when they want to use a field that > large. It means they're basically saying the requirement is a more > recent version of MySQL, which might well be something they're happy > with. Otherwise they have to know about that restriction and change to a > TextField. However Django isn't going to flat-out forbid such fields > just because older versions of one particular database backend have this > restriction. That would unfairly handicap everybody else because of a > problem in MySQL. Thus we make it a validation error only for particular > versions of MySQL. > > And, by the way, if you're not running "manage.py validate" every now > and again to check for errors like that, you should start doing so. We > only check that stuff when you run validate to avoid unnecessary > overhead at runtime, since development sanity checking should be done at > development time, not runtime. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
