Closed GeorgEchterling closed 3 months ago
I think this is caused by this part of DbSchedulerAutoConfiguration
, which was added in #357:
// Use custom JdbcCustomizer if provided.
builder.jdbcCustomization(
customizer
.jdbcCustomization()
.orElse(new AutodetectJdbcCustomization(transactionalDataSource)));
The default AutodetectJdbcCustomization
is created without receiving the configured value of alwaysPersistTimestampInUTC
. This also prevents the correct default in SchedulerBuilder#build
from working, since the jdbcCustomization
is always set in the auto-configuration:
final JdbcCustomization jdbcCustomization =
ofNullable(this.jdbcCustomization)
.orElseGet(
() -> new AutodetectJdbcCustomization(dataSource, alwaysPersistTimestampInUTC));
I think this can be fixed by simply removing the default jdbcCustomization
in DbSchedulerAutoConfiguration
. I.e.:
// Use custom JdbcCustomizer if provided.
customizer.jdbcCustomization().ifPresent(builder::jdbcCustomization);
🎉 This issue has been resolved in v14.0.1
(Release Notes)
Expected Behavior
Setting the Spring property
db-scheduler.always-persist-timestamp-in-utc=true
should create anAutodetectJdbcCustomization
withpersistTimestampInUTC = true
.Current Behavior
Setting
db-scheduler.always-persist-timestamp-in-utc=true
has no effect on the createdAutodetectJdbcCustomization
. TheJdbcCustomization
must be manually corrected via aDbSchedulerCustomizer
.In the case of MariaDB, the "utc_warning" still gets logged. It is also impossible to prevent this warning (except by silencing the logs), since even overriding the
JdbcCustomization
with a corrected version doesn't prevent theDbSchedulerAutoConfiguration
from temporarily creating the incorrect variant.For bug reports
Steps to Reproduce the bug
db-scheduler-spring-boot-starter
db-scheduler.always-persist-timestamp-in-utc=true
Context
Logs