[Java] Untyped nodes #1070
[Java] Untyped nodes #1070
Conversation
TODO. Tests in serialization libs
…andrueastman/untypedNodes
|
This pull request has conflicting changes, the author must resolve the conflicts before this pull request can be merged. |
|
Conflicts have been resolved. A maintainer will take a look shortly. |
|
This pull request has conflicting changes, the author must resolve the conflicts before this pull request can be merged. |
|
Conflicts have been resolved. A maintainer will take a look shortly. |
|
This pull request has conflicting changes, the author must resolve the conflicts before this pull request can be merged. |
|
Conflicts have been resolved. A maintainer will take a look shortly. |
andrueastman
requested review from
baywet,
MIchaelMainer,
zengin,
ramsessanchez and
Ndiritu
as code owners
|
This pull request has conflicting changes, the author must resolve the conflicts before this pull request can be merged. |
|
Conflicts have been resolved. A maintainer will take a look shortly. |
components/abstractions/src/main/java/com/microsoft/kiota/serialization/UntypedNode.java
Outdated
Show resolved
Hide resolved
| final JsonPrimitive primitive = element.getAsJsonPrimitive(); | ||
| if (primitive.isBoolean()) return new UntypedBoolean(primitive.getAsBoolean()); | ||
| else if (primitive.isString()) return new UntypedString(primitive.getAsString()); | ||
| else if (primitive.isNumber()) return new UntypedDouble(primitive.getAsDouble()); |
There was a problem hiding this comment.
when are we effectively using demical/float/long/integer? I know it can be hard to tell without the requested type and solely from from the data.
There was a problem hiding this comment.
I believe I did this because of the challenge you speak of. A similar implementation observed in the tryGetAnything() method at
I ended up keeping the other types as they can still be used during serialization though.
There was a problem hiding this comment.
The only thing I'm a bit worried about is the symmetrical aspect of it.
If somebody serializes as int, they'd probably expect to get an int back.
But I guess as long as this choice is consistent across languages, we can re-evaluate later based on customer feedback.
| final JsonPrimitive primitive = element.getAsJsonPrimitive(); | ||
| if (primitive.isBoolean()) return new UntypedBoolean(primitive.getAsBoolean()); | ||
| else if (primitive.isString()) return new UntypedString(primitive.getAsString()); | ||
| else if (primitive.isNumber()) return new UntypedDouble(primitive.getAsDouble()); |
There was a problem hiding this comment.
The only thing I'm a bit worried about is the symmetrical aspect of it.
If somebody serializes as int, they'd probably expect to get an int back.
But I guess as long as this choice is consistent across languages, we can re-evaluate later based on customer feedback.
|
This PR is related to microsoft/kiota#2319
It adds a number of types that implement the Parsable interface to enable the representation of types that are unknown at generation time to unblock the serialization and deserialization of properties of unknown types.
It also adds functionality to the serialization library of Json to be able to serialize and deserialize the types as well as tests for the scenarios.
Generation of these types is unblocked in microsoft/kiota#4095