Hey guys, a quick question on 5.x to 6.x migration...

# graphql-kotlin

[Martin Brehovsky]

Hey guys, a quick question on 5.x to 6.x migration. Looks like ID is now a value class. This makes a lot of sense, however it breaks one of our annotation processors - it cannot get annotations on properties with value class type (I asked why in kapt channel). Not sure if there is a quick fix for this in the annotation processor, so looking if it would be ok to wrap this ID in our own WorkaroundID class for now and add something to SchemaGeneratorHooks to emit this as an ID in the schema? Is this the right direction or is there a better solution to this problem? Thx!

[Dariusz Kuc]

👋 yeah I think custom class to represent ID (using custom hooks) is probably the best workaround

[Martin Brehovsky]

Thanks. Thinking about using willGenerateGraphQLType and return GraphQLTypeReference("ID") . Is this heading the right direction?

[Dariusz Kuc]

instead of ref I'd just return ID -> https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/Scalars.java#L56

[Martin Brehovsky]

Awesome, thanks for the pointer 🙂

[Dariusz Kuc]

you would have to make sure though that you have some custom logic to process both the input and output to serialize as just String

[Martin Brehovsky]

Well, that means I might need my own scalar implementing coercing to make sure this works completely transparently. Or is there a better mechanism in graphql-kotlin to specify additional rules for serializing the custom type?

[Dariusz Kuc]

Well by default types will be processed and serialized as the corresponding kotlin classe

[Dariusz Kuc]

Here the problem is that you want custom representation of a built in scalar primitive so server needs to know how to process it

[Dariusz Kuc]

Maybe the simplest way would be to use Any type as a field type and map it to ID and guess the coercing logic might work as is (as long as it is a string)

[Dariusz Kuc]

Unsure havent tried this use case

[Martin Brehovsky]

I'm now trying to use a custom class, expose it as Scalars.GraphQLID in SchemaGeneratorHooks and then inject a custom IDValueUnboxer to be able to translate to this ID. From 10k feet it looks like it should work, but still getting some some errors when running queries/mutations which use ID as a parameter:

SimpleDataFetcherExceptionHandler - Exception while fetching data (/updateConsumerAddress) : argument type mismatch

Read path seems to work fine.

[Adam Firen]

it's because the ID value is injected as a string to constructors have a look into com.expediagroup.graphql.generator.execution.FunctionDataFetcher#getParameters

I spent some time investigating why is that but end up with replacing ID with UUID extended scalar instead as it fit my domain better anyway.