Support enums in code generated models

[palpatim]

Given the following type:

public struct MutationEvent: Model {
    public enum MutationType: String, Codable {
        case create
        case update
        case delete
    }

    public let id: Identifier
    public let modelName: String
    public let json: String
    public let mutationType: MutationType
    public let createdAt: Date

    public init(id: Identifier = UUID().uuidString,
                modelName: String,
                data: String,
                mutationType: MutationType,
                createdAt: Date = Date()) {
        self.id = id
        self.modelName = modelName
        self.json = data
        self.mutationType = mutationType
        self.createdAt = createdAt
    }
}

extension MutationEvent {
    // MARK: - CodingKeys

    public enum CodingKeys: String, ModelKey {
        case id
        case modelName
        case json
        case mutationType
        case createdAt
    }

    public static let keys = CodingKeys.self

    // MARK: - ModelSchema

    public static let schema = defineSchema { definition in
        let mutation = MutationEvent.keys

        definition.attributes(.isSyncable, .isSystem)

        definition.fields(
            .id(),
            .field(mutation.modelName, is: .required, ofType: .string),
            .field(mutation.json, is: .required, ofType: .string),
            .field(mutation.mutationType,
                   is: .required,
                   ofType: .enum(type: MutationType.self)),
            .field(mutation.createdAt, is: .required, ofType: .dateTime)
        )
    }
}

Registering the type as a model fails:

2019-11-18 16:19:40.219199-0800 AmplifyTestApp[21061:3952734] Fatal error: Model with name MutationType could not be found.: file /Users/schmelte/src/github-repos/amplify-ios/Amplify/Categories/DataStore/Model/ModelSchema+Definition.swift, line 70

It looks like it's not going to be as simple as just detecting the type in ModelField.typeDefinition, since the incoming type on the field is MutationType, and I don't see any path to find that it's actually an enum.

[drochetti]

Quick update on this:

So far the best I could come up with was to introduce a new contract to enums, something like PersistableEnum:

enum PostStatus: String, PersistableEnum {
  case draft
  case published
}

protocol PersistableEnum {
    var enumValue: String { get }
}

extension PersistableEnum 
where Self: RawRepresentable, Self.RawValue == String {
    var enumValue: String { return rawValue }
}

if let value = PostStatus.draft as? PersistableEnum {
  print(value.enumValue)
}

that way we can always check Any for PersistableEnum conformance and call enumValue. Not 100% clear yet how I'm going to de-serialize a String back to PersistableEnum.

I tried using Swift built-in types only, like RawRepresentable<String>, StringRepresentable and CustomStringConvertible with no luck

[rodrigoelp]

Hello, trying to understand this issue (as I think I have just hit it and I created a ticket that might be duplicate of this one with a different symptom)

Assuming my schema is:

enum Gender {
  male,
  female,
}

type Person @model 
  (mutations: { create: "newPerson", update: "updPerson", delete: "delPerson"  } ) {
  id: ID!
  name: String!
  gender: Gender!
}

The generated enum is not supported at the time of applying a mutation, right?

I created a ticket indicating the enum doesn't conform with the Codable protocol but reading this ticket (and based on my current code that is crashing Fatal error: Model with name Gender could not be found.: file) I assume it is the same root cause.

If that is the case, I can close the #246 ticket as duplicate.

[palpatim]

There are actually 2 separate issues that you've correctly identified:

1. Codegen isn't conforming enums to Codable
2. DataStore expects the associated type to be a @model, which doesn't really make sense for enum values. We may in the end elect to treat them as models, but it doesn't seem right for a customer to have to tag an enum value with @model. We're working on this and will update when we have more info.

These two may end up devolving into a single root cause (again as you've correctly identified), but for now it makes sense to consider them separately.

[rodrigoelp]

Fair enough.

Looking forward to the decision.

[drochetti]

This was resolved by PR #334