Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Entity Individual Property Swift Type Override #176

Open
LePips opened this issue Dec 19, 2022 · 3 comments · May be fixed by #177
Open

Entity Individual Property Swift Type Override #176

LePips opened this issue Dec 19, 2022 · 3 comments · May be fixed by #177

Comments

@LePips
Copy link
Contributor

LePips commented Dec 19, 2022 •
edited

While property schema datatypes can be overridden, I need to be able to override a single entity property type.

Context

My schema has a few string properties that are represented by a collection of static strings on the backend. They are not specified in the schema as enums due to the complexity/time of refactoring to use those strings as enums.

So, I have my own Swift enums specified manually and would like to use that to fill in gaps of the schema.

Currently the following would be generated:

struct MyItem {
	let itemType: String
}

What should come from generation:

struct MyItem {
	let itemType: MyItemType
}

Implementation

Introduce new config option entities.propertyTypeOverrides which represents a mapping of scheme properties to Swift types:

entities:
  propertyTypeOverrides:
    MyItem.itemType: MyItemType

This option would take precedence over the datatype override and would follow the same rule:

It is your responsibility to ensure that the replacement type conforms to Codable and can properly decode and encode to the original primitive type.

While my example is specifically for a String -> enum case, I think this can be helpful in other contexts.
@LePips LePips linked a pull request Dec 19, 2022 that will close this issue
Open
@liamnichols
Copy link
Member

Hi @LePips, sorry that it took so long to get around to responding here and thanks for opening up the proposal!

Before looking deeper into this, is this something that could be similarly achieved by using a custom format value?

https://swagger.io/docs/specification/data-models/data-types/#format

format is an open type so you are able to use any value in the schema, even those that are not known to OpenAPI. So with this, could it be possible to annotate your schema with custom formats that represent different concepts and then provide a mapping via the existing dataTypes mappings?

dataTypes:
  string:
    concept-one: EnumRepresentingConceptOne
    concept-two: EnumRepresentingConceptTwo

Then in the schema:

properties:
  conceptTwo:
    type: string
    format: concept-two

@LePips
Copy link
Contributor Author

LePips commented Mar 6, 2023 •
edited

Thank you for your response and idea about using format!

I do see that performing some pre-processing to add or change the format modifier to achieve the ultimate goal is possible with the current state of the project. However, I make the point that it can be more difficult to perform and maintain over this solution which would only be a few additional lines in the config.

While format is a broad type override, being able to override individual property types allows much finer tuning at the generation level.

@LePips
Copy link
Contributor Author

LePips commented Apr 12, 2023

I went ahead and used the format modification as part of patching the schema prior to generation in my package. This proves that it is definitely possible to do so in that way but the proposed solution is much easier and won't require any patching of the schema.

@LePips LePips mentioned this issue May 24, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Entity Property Type Override LePips/CreateAPI
2 participants
@liamnichols @LePips