all languages | Generating enums from query parameter

[sirmrowa]

When the query parameter is defined as an enum, no code for this enum is generated.

OpenApi spec:

openapi: 3.0.3
info:
    title: TestApi
    version: 1.0.0
  
paths:
    /users:
        get:
            parameters:
                - name: type
                  in: query
                  schema:
                    type: string
                    enum: [TYPE1, TYPE2]
            responses:
                '204':
                    description: No content

Generates:

public class UsersRequestBuilderGetQueryParameters {
   public string? Type { get; set; }
}

where Type should be enum instead of string

[baywet]

Thanks for reporting this. It was a design decision at the time since serializing enums comes with constraints (as seen in #2488 )
This is something we'd need to address for version 2 of kiota since it'd be a binary breaking change in the case of C#

[sirmrowa]

@baywet Thanks for Your answer. Enums with constraints are another big story, but simple serializing works perfectly when an enum is part of a request/response object. Maybe this could be done in this release?

[baywet]

We can't as it'd be a binary breaking change.

Imagine somebody has the existing following code based on a client the generated with kiota

var result = await client.Path1.Path2.GetAsync(x => x.QueryParameters.Param1 = "value1");

If we switch the generation to enums, they'll have to update their code to when they refresh their client. Which violates our support policy.

var result = await client.Path1.Path2.GetAsync(x => x.QueryParameters.Param1 = EnumType.Value1);

The reason that support constraint is so people can update kiota's minor and patch versions trusting it won't break their clients and code.
I hope this additional context helps set the frame.

[sirmrowa]

@baywet You are right. This is a breaking change for already generated code.

[baywet]

note additional information for implementation can be found in #2306

[baywet]

Now that we've introduced a pattern where we could project both without leading to a breaking change (using obsolete annotations) in #2952, we should reconsider this one for 1.8

[baywet]

addressed with #3477