-
Notifications
You must be signed in to change notification settings - Fork 620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide way to encode unquoted String in JSON format #1405
Comments
Another use case is embedding known JSON documents into others without having to go through an intermediate parsing step. As long as it's named sufficiently scary this can be a powerful escape hatch. |
Should this issue also include support for decoding JSON primitives as raw strings (to be able to convert them to smth like mentioned |
Do you see any downsides to this approach? I suppose it might be prone to breaking, but it seems to work at least. Obviously it should only be used when working with json as serial format.
|
@Kantis thanks for sharing, seems to be working great! |
This solution unfortunately only works only for decoding. When encoding, the value will get converted to |
Darn. I accidentally asserted my expected too precise for double number through a JSON parser which ended up doing the same double-conversion. Added a warning to my original comment and code snippet. |
Thanks for sharing @DrMetallius, good to know the limitations. @sandwwraith looks like there's no viable workaround for serialization, would it be possible to proiritize the issue? |
I think we'll include this in plans for the next release |
@sandwwraith that's great to hear, thank you 🙏 |
any updates on this issue? |
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
The server does return vulnerabilities which do not have a severity value in the dedicated property. The unspecified `databaseSpecific` property often times holds a primitive `severity` property with values such as `[HIGH, MEDIUM, LOW]`. Make use of these values as a fallback as these to provide more indication than a `null` value. Note: The data model of 'osv/client' currently uses subtypes of JsonElement to expose a couple of unspecified JSON objects as properties. Accessing these requires the client code to add 'kotlinx.serialization' as dependency which is not nice. A solution to that would be to use "raw" string values containing the JSON, which is unfortunately not yet possible but may become so in the future, see [1][2][3]. So, for now add 'kotlinx.serialization' as dependency to the advisor in order to access the property and leave a FIXME comment as reminder. [1] Kotlin/kotlinx.serialization#1298 [2] Kotlin/kotlinx.serialization#1405 [3] Kotlin/kotlinx.serialization#1058 Signed-off-by: Frank Viernau <frank_viernau@epam.com>
@sandwwraith 👋 hello, I wonder if this is still planned. |
@nikolaykasyanov encoding raw strings to JSON was completed in #2041, and it will be available in a month or two. |
This PR provides a new function for encoding raw JSON content, without quoting it as a string. This allows for encoding JSON numbers of any size or precision, so BigDecimal and BigInteger can be supported. Fixes Kotlin#1051 Fixes Kotlin#1405 The implementation is similar to how unsigned numbers are handled. JsonUnquotedLiteral() is a new function that allows creating literal JSON content. Added val coerceToInlineType to JsonLiteral, so that JsonUnquotedLiteral could use encodeInline() Defined val jsonUnquotedLiteralDescriptor as a 'marker', for use with encodeInline() ComposerForUnquotedLiterals (based on ComposerForUnsignedNumbers) will 'override' the encoder when a JsonLiteral has the jsonUnquotedLiteralDescriptor marker, and will encode the content as a string without surrounding quotes.
Mainly to write big numbers. See reasoning here: #1051 (comment)
The text was updated successfully, but these errors were encountered: