Azure-sdk-for-java: Stellen Sie die Möglichkeit zur Verfügung, die JSON-Serialisierung anzupassen

Erstellt am 8. Juni 2019  ·  3Kommentare  ·  Quelle: Azure/azure-sdk-for-java

Öffentliche ObjectMapper-Referenzen entfernt, mit denen Benutzer die JSON-Serialisierung anpassen konnten.

Dies lag daran, dass Azure/azure-cosmosdb-java#153 eine bessere Option benötigt.

Client Cosmos Investigate v4-item feature-request

Alle 3 Kommentare

Nachdem ich den folgenden Blogbeitrag gelesen hatte: https://devblogs.microsoft.com/cosmosdb/difference-between-null-and-undefined/ fragte ich mich, wie ich das mit dem Java SDK erreichen könnte.
Der Standard-ObjectMapper ist so konfiguriert, dass Nullfelder immer serialisiert werden.

Ich bin darüber gestolpert, als ich meiner Entitätsklasse ein ttl -Feld hinzugefügt habe. Ich möchte beim Aktualisieren eines bestimmten Cosmos DB-Elements eine benutzerdefinierte TTL festlegen. Die meisten Elemente benötigen niemals eine benutzerdefinierte TTL und können einfach die Container-TTL verwenden. Daher wäre das Feld null.

Aber wenn ich das Feld ttl auf null setze, erhalte ich die folgende Fehlermeldung:

Die Eingabe ttl 'null' ist ungültig. Stellen Sie sicher, dass Sie eine positive ganze Zahl ungleich Null angeben, die kleiner oder gleich „2147483647“ oder „-1“ ist, was bedeutet, dass sie niemals abläuft.

Die Dokumentation hier besagt, dass das Setzen ttl auf null funktioniert, obwohl nicht ganz sicher ist, ob null dort dieselbe Bedeutung hat.

@kushagraThapar Ich würde hier gerne eine Lösung sehen, da dies einige fortgeschrittene Anwendungsfälle des SDK wirklich einschränkt. Vielleicht können Sie es also wieder aus dem "Parkplatz" entfernen und ihm eine höhere Prio zuweisen?

Beispielsweise können Sie Kotlin-Klassen nicht sofort verwenden, da https://github.com/FasterXML/jackson-module-kotlin nicht im statischen ObjectMapper registriert ist, der im SDK verborgen ist. Dies zwingt Sie dazu, Kotlin-Klassen manuell als sehr hässliche Problemumgehung zu kommentieren, um die Deserialisierung unveränderlicher Datenklassen zum Laufen zu bringen:

data class Email <strong i="9">@JsonCreator</strong> constructor(
    <strong i="10">@param</strong>:JsonProperty("email") val email: String // note the redundant specification of "email"
)

Oder machen Sie einen Hack wie den Aufruf Utils.getSimpleObjectMapper().registerModule(new KotlinModule()) auf dieser statischen ObjectMapper-Instanz zu einem frühen Zeitpunkt des Anwendungslebenszyklus.

Für @dkroehan wäre eine Problemumgehung die Verwendung <strong i="16">@get</strong>:JsonInclude(JsonInclude.Include.NON_NULL) (Kotlin) im Klassenfeld ttl .

@ xinlian12 - Gedanken zu diesem Thema?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen