This is working as intended; on most databases, inserting a 11 character text value into a VARCHAR(10) raises an error. On MySQL, depending on if strict mode is enabled*, it either inserts "just fine" by truncating "12345678901" to "1234567890" with a warning, or fails with an error.
As silent data corruption isn't a good thing Django currently turns the warning into an error, at least if DEBUG is set. Not all warnings are this evil so doing this in production is a no go, but the one in https://code.djangoproject.com/ticket/21163 is a clear case of programming error, inserting 11 chars into a max_length=10 field should fail without doubt, it's silly that MySQL accepts it at all. As for the unit test, in my opinion, there should be a test case for MySQL that asserts an error is thrown with DEBUG enabled and forcing a VARCHAR field overflow. In reality, it works now so no-one will touch this. * non strict is the default prior to MySQL 5.7.5. Strict mode in transactions is default for 5.7.5 and newer. Strict mode is off by default outside of transactions. On Saturday, 15 November 2014 18:08:34 UTC+1, Ilja Maas wrote: > > Investigating https://code.djangoproject.com/ticket/21163 > I came across these lines in mysql/base.py: > > if settings.DEBUG: > warnings.filterwarnings("error", category=Database.Warning) > > > Finding out why, this bubbles up to somewhere in 2007 > > https://github.com/django/django/commit/f9c4ce51235aac4862cfe2dfaaf6836acaea1c3d > > > I can't find the reason why this behaviour is in, other than the comments > in de commit mentioned before: "Since the point is to raise Warnings as > exception".. > > No arguments here.. Is there someone who actually knows the reasons? > It seems this code comes from the old MySQL days (pre 5/5.1) and a lot has > changed since in MySQL since then. > > However.. I think in DEBUG mode these warning should be shown as warnings > as they are warnings :-) an not being promoted to Exceptions. > Maybe even _every_ warning should be shown and not only the first one. The > example in the bug-report is about data-truncation. > It's not something like a deprecation warning. > > Coming to a conclusion _IMHO_ the different behaviour between debug mode > or not is somehow strange. > > The behaviour should be either promote warning to exceptions in > DEBUG=False (production) too, but that probably breaks a lot of django > implementations. > > or, get the promotion out. > > Any suggestions/ideas on this? > > > PS. > With these lines removed, none of the unittests fail. > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8d2ebbd5-bccc-44ca-bc1d-7ec3685465ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
