Skip to content
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

incompatible default sql_mode "STRICT_TRANS_TABLES" for MariaDB >= 10.2.4 partially breaks operation #764

Open
SvenRoederer opened this issue Jan 11, 2023 · 0 comments

Comments

@SvenRoederer
Copy link
Contributor

During recent upgrade of OS (Univention Corporate Server v4.8 --> v5.0) the database was upgraded from MariaDB10.1.48 to 10.3.36. With MariaDB 10.2.4 they changed the default sql_mode to include STRICT_TRANS_TABLES. This setting seems a reasonable default in general, but is incompatible to berliCRM.
As this change happend during distribution-upgrade there was nothing that pointed out the change and it took some time to find this problem. Only some functions of the CRM did not work, but most were doing fine.

Imho having the STRICT_TRANS_TABLES mode seems a reasonable default, that should be kept enabled globally. In addition to the global "sql_mode", that only can be changed by DB-admins, there is a per session "sql_mode" that can be changed by the client on per connection basis. in PR #757 I suggested a change to set the mode of a session, as the database-connection is persistent, I expect a minimal performance penalty only.
This change was rejected in favor of adding a test for sql_mode in the "installer". But the "installer" will not detect a change as described here, as the "installer" will never run after initial setup.

So 2 points:

  • How to handle conflicting global sql_modes on a shared server ? In my case I host a bunch of other databases on the same server along the CRM. other apps are fine with default having "STRICT_TRANS_TABLES" enabled
  • Instead relying on the "installer", a separate "check-install" tool, that can run anytime, seems more useful. So the tests can be shared between "installer" and "checker", but compatibility can be easily checked (e.g. after major upgrades of components)
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

No branches or pull requests

1 participant