How to completely disable discriminators

[ColOfAbRiX]

I'm writing a client in Scala 3 for a database that uses rest endpoints and I want to represent the requests internally using case classes which also include sealed traits/enum:

enum ServiceRequests:
  case RequestA(field1: String, field2: Int, ...) extends ServiceRequests

Because I'm interfacing with an existing service I cannot include any discriminator in the output json but I couldn't find how to. The only output I get is with a type field { "type": "RequestA", "field1": "...", "field2": "..." } or wrapped in another json object { "RequestA": { "field1": "...", "field2": "..." } } and none of these options are acceptable.

I couldn't find if this is possible and how to do it.

[plokhotnyuk]

@ColOfAbRiX Hi, Fabrizio!

Thanks for the question!

Unfortunately, there no simple direct solution for derivation of such codecs.

For your case there is a couple of workaround options:

• use additional data structures that match JSON more closely and then convert between them and your existing data structures using chimney or ducktape libraries
• derive codecs for concrete request classes, like val requestACodec = JsonCodecMaker.make[ServiceRequests.RequestA] and write your own custom codec to determine which of them should be used for parsing of incoming requests

I will be happy to help you in writing of some acceptable solution based on concrete JSON samples and data structures.

[ColOfAbRiX]

Thanks, probably the second of your suggestions feels the most appropriate, as I'm already working with the closest data structure to the api

[plokhotnyuk]

Also, to avoid XY problem, please give some context to understand why just using codecs for concrete case classes is not enough for your case? Why do you need extending of ServiceRequests for all of them and use a codec for abstract ServiceRequests instead?

As example, usually doing REST we use different paths for different types of requests, so corresponding concrete class codecs could be easily pattern matched by paths, no need for generic one for an abstract class...