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

Field 'location_browser_lang' doesn't have a default value In query #8853

Closed
pouyana opened this Issue Sep 25, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@pouyana

pouyana commented Sep 25, 2015

Hi there,
after migrating from MYSQL to MARIADB, and having STRICT_TRANS_TABLES on, I encounter the same error as #6028.
Error query: SQLSTATE[HY000]: General error: 1364 Field 'location_browser_lang' doesn't have a default value.
Any Help would be appreciated.
Piwik version the last stable 2.14.3

@tsteur

This comment has been minimized.

Show comment
Hide comment
@tsteur

tsteur Sep 29, 2015

Member

This might be actually introduced by https://github.com/piwik/piwik/pull/8589/files as we cannot define database updates currently we should maybe remove STRICT_TRANS_TABLES from the SQL mode? @mattab I can imagine that this problem will be faced by many users

Member

tsteur commented Sep 29, 2015

This might be actually introduced by https://github.com/piwik/piwik/pull/8589/files as we cannot define database updates currently we should maybe remove STRICT_TRANS_TABLES from the SQL mode? @mattab I can imagine that this problem will be faced by many users

@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Oct 6, 2015

Member

Fyi @tsteur: #8589 was introduced in 2.15.0-b3 but @pouyana is using 2.14.3

Member

mattab commented Oct 6, 2015

Fyi @tsteur: #8589 was introduced in 2.15.0-b3 but @pouyana is using 2.14.3

@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Oct 6, 2015

Member

@tsteur if you think it's something to investigate before 2.15.0 please move it to milestone

Member

mattab commented Oct 6, 2015

@tsteur if you think it's something to investigate before 2.15.0 please move it to milestone

@tsteur

This comment has been minimized.

Show comment
Hide comment
@tsteur

tsteur Oct 6, 2015

Member

Ideally we would make all columns nullable but this would be a big, long running update statement that we cannot do.

As STRICT_TRANS_TABLES will be enabled soon this cat hit many users maybe, not sure how it happens though. I can imagine eg disabling the UserLanguage plugin can break tracking, also disabling other plugins might break tracking if they define a dimension with a not null column.

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

Member

tsteur commented Oct 6, 2015

Ideally we would make all columns nullable but this would be a big, long running update statement that we cannot do.

As STRICT_TRANS_TABLES will be enabled soon this cat hit many users maybe, not sure how it happens though. I can imagine eg disabling the UserLanguage plugin can break tracking, also disabling other plugins might break tracking if they define a dimension with a not null column.

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

@tsteur tsteur added this to the 2.15.0 milestone Oct 6, 2015

@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Oct 6, 2015

Member

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

OK to play it safe, we probably should do this. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

Member

mattab commented Oct 6, 2015

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

OK to play it safe, we probably should do this. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

@mattab mattab self-assigned this Oct 7, 2015

mattab added a commit that referenced this issue Oct 7, 2015

Remove STRICT_TRANS_TABLES SQL mode to prevent fatal error
We cannot let tracking fail under any circumstance, but with STRICT_TRANS_TABLES, when a plugin is disabled, and the column is NOT NULL, then tracking would fail.

 Fixes #8853
@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Oct 7, 2015

Member

PR: #8930

Member

mattab commented Oct 7, 2015

PR: #8930

@mattab mattab closed this in #8930 Oct 7, 2015

@tsteur

This comment has been minimized.

Show comment
Hide comment
@tsteur

tsteur Oct 7, 2015

Member

. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

This would mean we need to update all dimensions to be nullable I guess. Also we need to check possible other tables for not nullable columns and whether they will be always set. Shall we create an issue?

Member

tsteur commented Oct 7, 2015

. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

This would mean we need to update all dimensions to be nullable I guess. Also we need to check possible other tables for not nullable columns and whether they will be always set. Shall we create an issue?

@mattab mattab added the Bug label Oct 13, 2015

@Joey3000

This comment has been minimized.

Show comment
Hide comment
@Joey3000

Joey3000 Oct 27, 2015

Contributor

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

OK to play it safe, we probably should do this. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

Just a remark: Using STRICT_TRANS_TABLES would require a bump of the minimum MySQL version to 5.0 on https://piwik.org/docs/requirements/. (Because according to https://dev.mysql.com/doc/refman/5.0/en/sql-mode.html, it was first introduced on 5.0.2, which was one of the alpha versions of 5.0 - see the "Table of Contents" in https://dev.mysql.com/doc/relnotes/mysql/5.0/en/.) See also #9088 (comment) for other SQL Mode values.
P.S.: Discussion on the increase of the minimum supported MySQL version in #9107.

Contributor

Joey3000 commented Oct 27, 2015

I guess we should remove STRICT_TRANS_TABLES from SQL modes for now but it would be good to have

OK to play it safe, we probably should do this. But, we can add it in 3.0 branch already, to bring best practise to the future major release. sounds good?

Just a remark: Using STRICT_TRANS_TABLES would require a bump of the minimum MySQL version to 5.0 on https://piwik.org/docs/requirements/. (Because according to https://dev.mysql.com/doc/refman/5.0/en/sql-mode.html, it was first introduced on 5.0.2, which was one of the alpha versions of 5.0 - see the "Table of Contents" in https://dev.mysql.com/doc/relnotes/mysql/5.0/en/.) See also #9088 (comment) for other SQL Mode values.
P.S.: Discussion on the increase of the minimum supported MySQL version in #9107.

@mattab

This comment has been minimized.

Show comment
Hide comment
@mattab

mattab Nov 18, 2015

Member

This would mean we need to update all dimensions to be nullable I guess. Also we need to check possible other tables for not nullable columns and whether they will be always set. Shall we create an issue?

Created an issue for this to fix the issue globally: Make all log_* tables fields NULLable to prevent errors "Field 'X' doesn't have a default value" #9231

Member

mattab commented Nov 18, 2015

This would mean we need to update all dimensions to be nullable I guess. Also we need to check possible other tables for not nullable columns and whether they will be always set. Shall we create an issue?

Created an issue for this to fix the issue globally: Make all log_* tables fields NULLable to prevent errors "Field 'X' doesn't have a default value" #9231

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment