Issues with TimeStamp when used for RDS that is backed by PostgreSQL

Offen
  • Stimmt etwas nicht?
#12 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
aws, java, postgresql
Bereich
api, databases

Rechercherichtung

Beginnen Sie mit der DateTimeParseException in TypeConverter.java:123 und verfolgen Sie, wie ExecutionResult.java:132 zurückgegebene Zeitstempelfelder konvertiert. Reproduzieren Sie den PostgreSQL/RDS-Wert mit zwei Nachkommastellen und fügen Sie anschließend einen Regressionstest für das Parsen hinzu; die angeforderte Unterstützung für Instant und java.sql.Timestamp sollte separat bewertet werden, bevor sie als erledigt betrachtet wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

I created an integration test that uses version 2.0.0 of the ads-data-api-client-library and writes and then retrieves data to a table with a timestamp column..

When retrieving a timestamp value that has millis mod 10 = 0, e.g. 2022-04-06 22:58:48.990 (or as displayed on the RDS query tool in the Aws console 2022-04-06 22:58:48.99), an exception is thrown, like so:

java.time.format.DateTimeParseException: Text '2022-04-06 22:58:48.99' could not be parsed, unparsed text found at index 19

0 = {StackTraceElement@6106} "java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2049)"
1 = {StackTraceElement@6107} "java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1874)"
2 = {StackTraceElement@6108} "com.amazon.rdsdata.client.TypeConverter.fromField(TypeConverter.java:123)"
3 = {StackTraceElement@6109} "com.amazon.rdsdata.client.ExecutionResult$Row.getValue(ExecutionResult.java:132)"

It appears that the parsing format does not properly deal with a date time string that doesn't have the 3rd digit to the right of the decimal place.

I have worked around this by adding one millisecond to date time values for which datetimevalue.toEpochMillis % 10 == 0,
e.g.

fun Instant.asRDSLocalDateTime() : LocalDateTime {
    // Kuldge to deal with RDS formatting and parsing - date time values that don't have 3 digits of milli seconds , e.g. 2022-04-06 23:12:00.12 fail to parse due to RDS Client
    // example exception: java.time.format.DateTimeParseException: Text '2022-04-06 22:58:48.99' could not be parsed, unparsed text found at index 19
    var truncated = this.truncatedTo(ChronoUnit.MILLIS)
    if (truncated.toEpochMilli() % 10L == 0L) {
       truncated= truncated.plusMillis(1L)
    }
    return LocalDateTime.ofInstant(truncated,ZoneOffset.UTC)
}

Ever since I did that, I no longer get exceptions.

Should be simple to fix, just change the format string.

While you are in there, could you add support for Instants? Coverting back and forth to LocalDateTime is tedious.

And, while your at it, it would be easier to use the rds-data-api-client-library-java if it supported the java.sql types, e.g. TimeStamp. It would result in less boilerplate.

Thanks

Vorherrschende Sprache
Java
Sterne
21
Forks
5
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus awslabs/rds-data-api-client-library-java

Alle Issues in awslabs/rds-data-api-client-library-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.