mysql - Can someone explain this model.save() behavior in Django, test server vs. Apache? -

i have django model contains, among other things, product field restricted 128 characters:

class sku(models.model):     ...     product = models.charfield(max_length=128, null=true, blank=false)     ... 

at 1 point in app, read in user data , make sku out of it, , save it. turns out, data goes product field exceeds specified size of 128 characters. when app being served apache through wsgi, sku.save() command emits warning:

/library/frameworks/python.framework/versions/2.7/lib/python2.7/site-packages/django/db/backends/mysql/base.py:114: warning: data truncated column 'product' @ row 1  

… that's is, warning. sku saved, , contents of product field truncated 128 chars. however, when i'm testing django's built-in test server, sku.save() command results in crash, , following (abbreviated) stack trace:

file "/library/webserver/documents/acdc_cmd/trunk/promotions/promo_parsers.py", line 467, in createkitsandcontents    thesku.save()  file "/library/frameworks/python.framework/versions/2.7/lib/python2.7/site-packages/django/db/models/base.py", line 463, in save self.save_base(using=using, force_insert=force_insert, force_update=force_update) ... file "/library/frameworks/python.framework/versions/2.7/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 114, in execute   return self.cursor.execute(query, args) file "/library/frameworks/python.framework/versions/2.7/lib/python2.7/site-packages/mysql_python-1.2.4b4-py2.7-macosx-10.6-intel.egg/mysqldb/cursors.py", line 204, in execute if not self._defer_warnings: self._warning_check() file "/library/frameworks/python.framework/versions/2.7/lib/python2.7/site-packages/mysql_python-1.2.4b4-py2.7-macosx-10.6-intel.egg/mysqldb/cursors.py", line 117, in _warning_check warn(w[-1], self.warning, 3) warning: data truncated column 'product' @ row 1 

in case, sku.save() crashes program. means result of import operation different on test server , when served apache. have following questions:

1. how django different stuff in these 2 (apache vs. test server) cases?
2. is there way explicitly indicate in code: save sku, it's okay truncate fields according model definition?
3. is there better way handle this?

wrt #3, can imagine introspecting model's field definition, , manually truncating character string before try save it; that's lot of messing around. suspect there's front-door way accomplish this, can't find it.

indeed weird situation. recommendations here:

first, should try avoid situation @ all. no matter if apache save data right, should try remove warnings.

the best way truncating data in relevant places. not difficult nor messed.

first, suggest include javascript code form give user feedback he's doing wrong possible. client-side code secure, should move on , add line

product=forms.charfield(max_length=128 ...) 

in skuform(no matter normal form or modelform. know said instrospecting model messy might severe security issue worth doing it. can manually truncate string overriding save method in either model or form -or in both if feel paranoic :).

it lot simpler this:

request.post['product']=request.post['product'][:128] 

but sadly won't work because request.post of type querydict , inmutable, can't modify it. copy dictionary new 1 , pass object form instead of request.post don't know more messy.

i'm sorry don't have answer why django behaves different in production/dev environment. know old versions of mysql behave way describe (truncating if varchar longer specified, , new versions forbid cant turn on twisting internals settings in database engine.

i hope helps. luck!