Custom convert incoming long for date and datetime types #36263
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
octavia-squidington-iii
added
area/connectors
octavia-squidington-iii
added
the
area/documentation
rodireich
changed the title
| return localDateTime.format(DateTimeFormatter.ofPattern(DATETIME_FORMAT_MICROSECONDS)); | ||
| } | ||
|
|
||
| if (input instanceof final Long d) { |
There was a problem hiding this comment.
Is it the case that for Mssql that all timestamp 'numbers' are always with nanosecond precision?
There was a problem hiding this comment.
We're only seeing this Long input when values are converted as part of acquiring schema history.
Dates on actual row records are still seen as incoming TimeStamp. None of this is documented anywhere as far as I can tell.
We need to take a close look at some point as this area is uneven in terms of implementation.
And some of the code here is almost three years old.
|
/publish-java-cdk dry-run=true
|
…ng-mssql-first-sync-long-cannot-be-cast-to-class-javasqltimestamp
|
/publish-java-cdk
|
rodireich
deleted the
35946-failure-in-date-time-conversion-during-mssql-first-sync-long-cannot-be-cast-to-class-javasqltimestamp
branch
Date types included in tables as default values are discovered in debezium with an input of either epoch milliseconds (for Datetime types) or epoch days (for date type).
Our custom converter couldn't convert this input.
Added correct conversion for schema history phase.
Actual record Dates are still seen as an incoming TimeStamp.