8000 Add UUID to kotlinx.serialization · Issue #362 · cjbooms/fabrikt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add UUID to kotlinx.serialization #362

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

Closed
alex-rieger opened this issue Feb 4, 2025 · 6 comments
Closed

Add UUID to kotlinx.serialization #362

alex-rieger opened this issue Feb 4, 2025 · 6 comments

Comments

@alex-rieger
Copy link

Hello,

When using kotlinx.serialization strings with format: uuid are converted to String in models, while Jackson serialization generates UUID. I think it would be a good addition if kotlinx.serialization is also able to produce UUID. Directly having UUID would eliminate the need to convert UUID <> String when working with e.g. Exposed.

Is this something that could be done? I'd be happy to open a pull request for it.

I found the following code in kotlin/com/cjbooms/fabrikt/model/KotlinTypeInfo.kt:

 OasType.Uuid -> {
  if (MutableSettings.serializationLibrary() == KOTLINX_SERIALIZATION) Text // could possibly be Kotlin native UUID once that becomes stable
  else Uuid
}

As far as I'm aware Kotlin's Uuid is not stable yet. Maybe this feature could be added as Type Override so users can choose whether it will be UUID / String (Uuid in future)?

Examples

openapi: 3.1.0

components:
  schemas:
    Pet:
      type: object
      required:
        - id
      properties:
        id:
          type: string
          format: uuid
// kotlinx.serialization
package com.example.models

import javax.validation.constraints.NotNull
import kotlin.String
import kotlinx.serialization.SerialName
import kotlinx.serialization.Serializable

@Serializable
public data class Pet(
  @SerialName("id")
  @get:NotNull
  public val id: String,
)

// Jackson serialization
package com.example.models

import com.fasterxml.jackson.`annotation`.JsonProperty
import java.util.UUID
import javax.validation.constraints.NotNull

public data class Pet(
  @param:JsonProperty("id")
  @get:JsonProperty("id")
  @get:NotNull
  public val id: UUID,
)
@ulrikandersen
Copy link
Collaborator
ulrikandersen commented Feb 5, 2025

Hi @alex-rieger,

Since kotlinx.serialization does not have a built in serializer for UUID it was decided to ignore the format and fall back to string. The same applies for format: uri (and actually also for format: number which currently maps to BigDecimal, which will not compile and needs to be fixed).

Serializer has not been found for type 'UUID'. 
To use context serializer as fallback, explicitly annotate type or property with @Contextual

It is possible to provide a custom serializer for these types using the @Contextual (docs) annotation.

We could probably add an option to make fabrikt generate add @Contextual to the fields in question instead of falling back to string.

Would that solve your use case?

@alex-rieger
Copy link
Author
alex-rieger commented Feb 11, 2025

Hi @ulrikandersen

thanks for the detailed insights I was not aware of @Contextual!
I think your proposed option would be a good fit for my use case.

I'd also be happy to tackle this issue if you decide that it has a place in the library :)

@ulrikandersen
Copy link
Collaborator
ulrikandersen commented Feb 13, 2025

You're welcome 🙂 I think it would be a nice addition to the library.

It would be great to have you contribute, but I already started working on a solution last week motivated by need for a custom serializer for BigDecimal (#364).

I have just opened a PR with the proposed changes here: #368. Perhaps you could you take a look?

@alex-rieger
Copy link
Author
alex-rieger commented Feb 16, 2025

I messed around a bit with the version in #368 and regenerated my models & controllers with it.
From my point of view, it works really well and solves my usecase.

Thank you!

@ulrikandersen
Copy link
Collaborator

Great to hear, Alex!

#368 is merged and I am confident that a new release will be out soon! 👀

@alex-rieger
Copy link
Author

Thanks for implementing! I'm looking forward to checking out the new release 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0