Skip to content

[5.3] Enabled MySQL "strict" mode by default #3777

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 11, 2016

Conversation

Adam14Four
Copy link
Contributor

When "strict" mode is set to false it allows the database to ignore significant errors rather than abort and return the error to PHP. An example would be trying to save a string in an INT field...instead of throwing an error, the save completes successfully and simply inserts a 0 in the field.

This means that the default setting allows for data loss with no notification, which seems like a really bad thing. The default should be to the safest setting, which could then be reconfigured by the developer if necessary.

@scoutman57
Copy link

YES!!!

@GrahamCampbell GrahamCampbell changed the title Enabled MySQL "strict" mode by default [5.3] Enabled MySQL "strict" mode by default May 10, 2016
@shehi
Copy link

shehi commented May 11, 2016

I hope ORM isn't depending on something non-strict.

@curquhart
Copy link

curquhart commented May 11, 2016

I feel like this could create potential issues. Strict mode also (at least, off the top of my head):

  • disallows division by zero, where the developer may be counting on it being set to NULL (non-strict behaviour)
  • disallows inserts if any column is non-nullable, doesn't have an explicit default value, and isn't included in the field list of said insert.
  • disallows the date 0000-00-00 (admittedly NULL makes more sense than 0000-00-00 but allowing NULL requires an extra byte of storage). It also disallows dates such as 2016-00-00 but that is just a stupid date so I'm on board for that being disallowed.

I feel like it should just be up to the developer to validate their data ;) but I guess it's an easy enough config change to reverse if preferences necessitate it.

@taylorotwell taylorotwell merged commit 6f4c333 into laravel:develop May 11, 2016
@taylorotwell
Copy link
Member

I think this makes sense and we'll document it. Timestamps in Laravel have defaulted to nullable for a while now to avoid errors with strict mode.

@taylorotwell
Copy link
Member

And as @chelseau notes, easy to reverse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants