Tags: adambrangenberg/Exposed
Tags
chore: Bump Exposed version from 0.42.1 to 0.43.0, and add 0.43.0 cha… …nges to ChangeLog.md
-
Aug 28, 2023 - 7b5f871
- zip 8000 a>
- tar.gz
fix: EXPOSED-130 Logger throws ClassCastException with JSON and ListS… …erializer (JetBrains#1835) * fix: EXPOSED-130 Logger throws ClassCastException with JSON and ListSerializer When a json/jsonb column is created that takes a List or ListSerializer, it correctly deserializes/serializes the json array to and from the database. However, attempting to log the statements involved throws ClassCastException, whereas there is no issue if the column is created to take an Array or ArraySerializer instead. The former extend Iterable, which is being handled separately in ColumnType.valueToString(). Overriding this branch to directly use the result of nonNullValueToString() fixes the logger issue.
test: Fix failing datetime tests in MariaDB (JetBrains#1805) * test: Fix failing datetime tests in MariaDB The following tests in exposed-java-time and exposed-kotlin-datetime fail when run using MariaDB: KotlinTimeTests/'test string LocalDateTime with nanos'() JavaTimeTests/'test string LocalDateTime with nanos'() - Fails with the message `Failed on microseconds` because Exposed's assertion functions for the fractional part are using `roundToMicro()` to compare nanoseconds. In other databases (DB), including MySQL, the nanoseconds retrieved from the DB is rounded to the internal precision using RoundingMode.HALF_UP. MariaDB always rounds down. - These tests are flaky because they rely on Clock.System.now() (and the java equivalent) and add a set amount of nanoseconds to a dynamic datetime value. This means any resulting value on the lower half of a microsecond will be round down and pass. - The assertion has been changed to floor the nanoseconds value instead and the test now takes 2 values with constant nanoseconds to evaluate what happens when the value is low versus high.
PreviousNext