Hi, We are now using a compromise to the starter, we use the graphql-kotlin-schema-generator. So fa...

# graphql-kotlin

[huehnerlady]

Hi,

We are now using a compromise to the starter, we use the graphql-kotlin-schema-generator.
So far it works well. We use Type Aliases for BigDecimal to make it clearer what it actually is (percent/euro).
How do I get these typeAliases as Scalars into the schema? I saw this page explains custom scalars very nicely. BUT I was wondering if it would be possible to reuse the scalar that seems to exist for BigDecimal already? At least the mapping seems to work, but in the schema it says just BigDecimal, even if we have the typealiases in place.

[Dariusz Kuc]

hello 👋 schema generation process knows nothing about your type aliases - you would need to manually register custom scalars corresponding to the type aliases (they could all be represented as big decimal)

[huehnerlady]

@Dariusz Kuc thanks. But how can I reuse the coercing from the bigDecimal? I could not find anything int he lib with the scalars, so was thinking this seems to be done somewhere under the hood?

So basically how can I do this without having to reimplement the coercing of BigDecimal?

[Dusan Hornik]

Hi Ruth, we use typealiases to get some benefits from strongly typed entityIds. Attached is a snippet of code that shows how LongCoercing is reused for multiple typealiases PatientId QuestionId and ApplicationId
Unfortunately, typealias is often presented as original type (Long) making it difficult to map from scalar back to typealias. We have a very hacky way type.toString() that is very ugly but seems to do the job.

Untitled

[huehnerlady]

@Dusan Hornik many thanks for your code snippet, this is very helpful. So does this mean that there is no possibility to reuse the Coercing for BigDecimal in this case? So I have to reimplement this functionality? I would have thought that you can just return a BigDecimal in that case and the type alias can understand that? But maybe I am too naive? 😅

[Dariusz Kuc]

@Dusan Hornik technically you don’t have to coerce string to long -> you could do long<->long (https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/scalar/GraphqlLongCoercing.java)

[Dariusz Kuc]

similarly for BigDecimal (https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/scalar/GraphqlBigDecimalCoercing.java) but in case of big decimal i’d probably use string

[Dariusz Kuc]

@huehnerlady you can reuse coercing for different scalars (to provide custom names)

[Dariusz Kuc]

but as was provided in the example code above you will have to register all custom scalars in the hooks

[huehnerlady]

that is super, I like the compromize. For me my main problem was to have to reimplement the Coercing and I could not find it, so I got all I need now, thank you so much 🙂

[huehnerlady]

just seen that this class is marked as internal 😞 I will contact them and ask wky that is

[Dariusz Kuc]

note that extended scalars will be removed in future version of graphql-java (and moved to extended scalars repo I believe)

[Dariusz Kuc]

those classes are internal as they contain internal library logic (which generally is not to be reused)

[Dariusz Kuc]

i’d recommend to just implement it in your repo

[huehnerlady]

yeah I think this is the best way. I am always trying to avoid duplicating code, but yeah maybe it makes sense in this case 🤔