OK, sorry, so maybe a bit more explanation. What I meant is:
- in general it is suggested to stick to sql_mode set globally on the
- still, client can change sql_mode for the given connection session.
Now, do you say that freshly installed racktables sets different sql_mode,
which is different to the one set when racktables is upgraded?
I believe this could be tracked by enabling logging of all sql queries for
Another question, does that happen only during application upgrade, or
maybe other components (like sq/web server...)
Is there an issue ticket for that?
On Wed, Nov 7, 2018 at 12:53 PM Denis Ovsienko <denis@xxxxxxxxxxxxx> wrote:
---- On Wed, 07 Nov 2018 16:02:24 +0000 Michał Sochoń <kaszpir@xxxxxxxxx>
> SQL_MODE management it's outside of the rackables responsibility.
> SQL_MODE is related to the mysql configuration, and it depends on the
state of the configuration for given mysql instance. That means it behaves
differently if you create fresh mysql instance or execute upgrade. System
admins can control if the config files should be updated during the process
> Racktables as an application should just adapt to the SQL_MODE which is
shipped with default fresh mysql server installation, and there should be
note in the racktables release about that mysql change setting and how it
> From what I remember SQL_MODE in newer versions of mysql are more
strict, and thus closer to official PL/SQL standard.
I am sorry Michal, but on this occasion what you say is wrong. To be able
to work with assorted versions of MySQL and MariaDB, RackTables manages its
session SQL mode as suggested in respective documentation guides. This is
the intended use of this feature.
The bit I need help with is that the pre-release checklist yields a diff
in SQL_MODE that should not be there, and last time I looked into it I
could not explain it.