Custom SQL executed not showing up in 4.x versions of Liquibase with the INFO verbosity level

Environment

Liquibase Version: 4.0.0 or above Liquibase Integration & Version: CLI, maven

Operating System Type & Version: Any

Database: Any supported platform

Description

When executing SQL with the update command combined with INFO log level the SQL executed does not show up with 4.0.0 or above.

Steps To Reproduce

1. Use Liquibase version 4.1.1

Create a changeLog with a create table changeset. For example:

--liquibase formatted sql

--changeset SteveZ:45555-createtablecontacts
CREATE TABLE contacts (id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,firstname VARCHAR(255),lastname VARCHAR(255));
--rollback drop table contacts;

Run: "liquibase --logLevel=info update"

Actual Behavior

$ liquibase --logLevel=info update
Starting Liquibase at 15:51:17 (version 4.1.1 #10 
built at 2020-10-12 19:24+0000)[2020-10-22 
15:51:18] INFO [liquibase.lockservice] 
Successfully acquired change log lock[2020-10-22 
15:51:19] INFO [liquibase.changelog] Reading from 
public.databasechangelog[2020-10-22 15:51:19] 
INFO [liquibase.changelog] Custom SQL executed
[2020-10-22 15:51:19] INFO [liquibase.changelog] ChangeSet changelog.postgresql.sql::45555-createtablecontacts::SteveZ ran successfully in 59ms
[2020-10-22 15:51:19]INFO [liquibase.lockservice] Successfully released change log lockLiquibase command 'updateCount' was executed successfully.

Expected/Desired Behavior

The output should include the following SQL (this is in Liquibase 3.10.2) For example:

Starting Liquibase at Thu, 22 Oct 2020 17:12:41 CDT (version 3.10.2 #22 built at Mon Jul 27 04:21:02 UTC 2020)
17:12:42.278 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.294 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT COUNT(*) FROM public.databasechangeloglock
17:12:42.297 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT COUNT(*) FROM public.databasechangeloglock
17:12:42.302 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
17:12:42.337 INFO  [liquibase.lockservice.StandardLockService]: Successfully acquired change log lock
17:12:42.338 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.527 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT MD5SUM FROM public.databasechangelog WHERE MD5SUM IS NOT NULL LIMIT 1
17:12:42.530 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT COUNT(*) FROM public.databasechangelog
17:12:42.533 INFO  [liquibase.changelog.StandardChangeLogHistoryService]: Reading from public.databasechangelog
17:12:42.534 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT * FROM public.databasechangelog ORDER BY DATEEXECUTED ASC, ORDEREXECUTED ASC
17:12:42.547 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.557 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.574 INFO  [liquibase.executor.jvm.JdbcExecutor]: CREATE 
TABLE contacts (
  id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  firstname VARCHAR(255),
  lastname VARCHAR(255)
)
17:12:42.591 INFO  [liquibase.changelog.ChangeSet]: Custom SQL executed
17:12:42.593 INFO  [liquibase.changelog.ChangeSet]: ChangeSet changelog.postgresql.sql::45555-createtablecontacts::SteveZ ran successfully in 37ms
17:12:42.596 INFO  [liquibase.executor.jvm.JdbcExecutor]: SELECT MAX(ORDEREXECUTED) FROM public.databasechangelog
17:12:42.848 INFO  [liquibase.executor.jvm.JdbcExecutor]: INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('45555-createtablecontacts', 'SteveZ', 'changelog.postgresql.sql', NOW(), 5, '8:762f4f2f9b31cb411865bace78aa42b3', 'sql', '', 'EXECUTED', NULL, NULL, '3.10.2', '3404762545')
17:12:42.861 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.866 INFO  [liquibase.lockservice.StandardLockService]: Successfully released change log lock
17:12:42.867 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.869 INFO  [liquibase.executor.jvm.JdbcExecutor]: SET SEARCH_PATH TO public
17:12:42.872 INFO  [liquibase.integration.commandline.Main]: Liquibase: Update has been successful.

[nvoxland]

This is by design. As part of the 4.0 logging cleanup, we standardized on java.util.logging.Logging defintions of log levels:

• SEVERE is a message level indicating a serious failure. In general SEVERE messages should describe events that are of considerable importance and which will prevent normal program execution.
• WARNING is a message level indicating a potential problem.
• INFO is a message level for informational messages. Typically INFO messages will be written to the console or its equivalent.
• FINE is a message level providing tracing information.

Prior to 3.6, the sql logging by JdbcExecutor was logged at FINE level because it is verbose, it can contain secure information that people don’t want included in their default logs, and because it’s not something we include it in the console output. With 3.6, a larger change was brought in which included moving this particular log message from FINE to INFO and we did not notice it for a while. Because the change had been in the wild for a while and we were planning for a better standardization of log rules in 4.0, we decided to leave the (probably) wrong level in the rest of the 3.x versions until we had a for-sure answer on what level it should be at.

After having finalized the log level standards and discussing the security implications of keeping the sql output at INFO level, we decided to put it back to FINE level.

If users would like to still see the log messages, they can configure their logger to output either all FINE level logs, or set just the liquibase.executor channel to FINE.

One final reason behind putting the log level back is because that particular debug message was never intended to be a way to track the SQL being executed. Much of the SQL ran would go through that message, but not all of it. Having it as visible as it is at the INFO level makes it too easy for users to assume it is a complete and accurate list of the SQL being executed vs. the specific component-level logging that it actually is. Currently, the updateSQL, rollbackSQL, type operations are the “correct” way to see the SQL that will be executed.

[FBurguer]

this issue its stale, so i think we should leave things as they are with the --sql-log-level option.