amplify-category-api
amplify-category-api copied to clipboard
aws-amplify
Gen2: Cannot create a model identifier based on an enum
How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
20.10.0
Amplify CLI Version
0.12.0-beta.4
What operating system are you using?
Chromebook/Linux
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
none
Describe the bug
I'm trying to create a Gen2 model with an enum as the identifier:
const schema = a.schema({
CategoryEnum: a.enum([
'INFO',
'WARNING',
'FATAL',
]),
Severity: a
.model({
category: a.ref('CategoryEnum').required(),
displayName: a.string().required(),
description: a.string().required(),
})
.identifier(['category'])
.authorization([
a.allow.owner(),
])
});
I get this typescript error:
Type '"category"' is not assignable to type 'IdentifierFields<{ fields: { category: RefType<SetTypeSubArg<RefTypeArgFactory<"CategoryEnum">, "valueRequired", true>, "required", undefined>; displayName: ModelField<...>; description: ModelField<...>; }; identifier: "id"[]; secondaryIndexes: []; authorization: []; }>'.ts(2322)
Expected behavior
Accept the enum as an identifier; this was possible in Gen1
Reproduction steps
const schema = a.schema({
CategoryEnum: a.enum([
'INFO',
'WARNING',
'FATAL',
]),
Severity: a
.model({
category: a.ref('CategoryEnum').required(),
displayName: a.string().required(),
description: a.string().required(),
})
.identifier(['category'])
.authorization([
a.allow.owner(),
])
});
Project Identifier
No response
Log output
# Put your logs below this line
Additional information
No response
Before submitting, please confirm:
- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [X] I have removed any sensitive information from my code snippets and submission.
Hi @MKlaeui we are aware of this issue and are working to resolve it by GA for Gen 2.
@chrisbonifacio I believe this was missed, and you just bumped all packages to 1.0.0 (which sounds like GA to me)
@hardchor Apologies for closing this prematurely. I think I might've mistaken this issue with one that was fixed recently regarding using enums as sort keys in composite primary keys and secondary indexes. The team has been made aware of this issue and is being discussed internally.
Might be worth noting that while this was possible in Gen 1, using an enum for a partition key would be considered an anti-pattern and can lead to hot partitions with enough throughput because of being low cardinality. For DynamoDB to function efficiently, it needs a high cardinality (many possible values) in the partition key.
That being said, we still intend to have feature parity with Gen 1 here, just want to encourage best practices.
@chrisbonifacio i agree that it could be considered an anti pattern, and to be honest I can't even remember when I encountered this to be an issue. There are very few scenarios where I could even imagine needing this (storing config for static values in the DB? Or maybe not even DB related, e.g. retrieving a subschema by a fixed key via custom resolvers from an API?). Either way I'm not sure if partitioning is a real issue due to the nature of enum usage in the real world, but I might be mistaken.