Search first

• I searched and no similar issues were found

Description

Problem

With the release of v4.32.0, the Neo4j extension has 2 commented-out assertions with regards to the conversion of datetimes with zone offsets, as you can see in this commit.

One such example is with loadData:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog https://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsd">

    <changeSet id="customer-import" author="asanturbano">
        <loadData
                file="e2e/load-data/data.scsv"
                separator=";"
                tableName="CsvPerson">
            <column name="first_name" header="name" type="string"/>
            <column name="wisdom_index" header="age" type="numeric"/>
            <column name="some_date" index="2" type="date"/>
        </loadData>
    </changeSet>
</databaseChangeLog>

name;age;some_date
Andrea;32;2020-07-12T22:23:24+02:00

This is an issue for Neo4j, since Neo4j supports properties of type datetime with offsets (as you can read here).

Liquibase core converts 2020-07-12T22:23:24+02:00 to a java.sql.Timestamp instance.
At that point, all the offset information is lost and the Neo4j extension treats Timestamps as local datetimes (which they normally represent).

Prior to v4.32.0, Liquibase core was converting such an offset datetime to a liquibase.statement.DatabaseFunction. This was strange for sure, but the extension had at least access to the raw string value which it could turn back to the desired ZonedDateTime that Neo4j supports.

Currently, neither ColumnConfig (for <insert>) nor LoadDataColumnConfig (for <loadData>) carry the original string value, making workarounds out of reach.

Proposal

I believe the easiest fix is to store the raw String value in ColumnConfig and LoadDataColumnConfig so that the Neo4j extension can at least re-parse them into the desired ZonedDateTime.

Steps To Reproduce

• Clone https://github.com/liquibase/liquibase-neo4j
• Uncomment the assertions in liquibase.ext.neo4j.e2e.InsertIT and liquibase.ext.neo4j.e2e.LoadDataIT
• Run mvn verify (requires a Docker daemon)

and you will see the failure.

Expected/Desired Behavior

Ideally, such date times with time zone name and/or offsets should be parsed as ZonedDateTime, even if that required a second translation round for most of the relational databases Liquibase core supports, since they'll not understand such values (I'm not even 100% convinced the conversion to java.sql.Timestamp is the right default, maybe users should have a way to store the time zone information in one field and the timestamp in another).

If this proves too costly, storing the original string value in the column config classes will allow the Neo4j extension to re-parse the original datetime values.

Liquibase Version

v4.32.0

Database Vendor & Version

Neo4j

Liquibase Integration

core

Liquibase Extensions

liquibase-neo4j

OS and/or Infrastructure Type/Provider

No response

Additional Context

No response

Are you willing to submit a PR?

• I'm willing to submit a PR (Thank you!)