1👍
Indeed is a weird situation. My recommendations about it are here:
First, you should try to avoid the situation at all. No matter if apache save the data right, you should try to remove all the warnings.
The best way to do this is by truncating yourself the data in all relevant places. Is not difficult nor messed.
First, I suggest you include some javascript code to the form to give the user the feedback that he’s doing something wrong as soon as possible. With the client-side code secure, you should move on and add the line
product=forms.CharField(max_length=128 ...)
in the SKUForm(no matter it is a normal Form or a ModelForm. I know you said that instrospecting into the model would be very messy but this might be a severe security issue so is worth doing it. You can manually truncate the string overriding the save method in either your model or your form -or in both if you really feel paranoic :).
It would be a lot simpler to do something like this:
request.POST['product']=request.POST['product'][:128]
but sadly that won’t work because request.POST is of type QueryDict and is inmutable, so you can’t modify it. You could copy the dictionary to a new one and pass that object to the form instead of request.POST but I don’t know what would be more messy.
I’m sorry I don’t have the answer to why Django behaves different in production/dev environment. I know old versions of MySql behave the way that you describe (truncating if the varchar is longer than specified, and new versions forbid this but you cant turn it on twisting some internals settings in the database engine.
I hope this helps. Good luck!