Closed rjlohan closed 5 years ago
This identifier should globally, uniquely identify an instance of the modeled resource and can be relied on to never change for the life of a resource.
it should be noted that for backwards compatibility, some resources will use whatever CloudFormation had previously chosen for the PhysicalResourceId (the property returned by Ref), which may not be the most global property.
Also, it should be emphasized that like the additionalIdentifiers, the primaryIdentifier MUST be able to be used in READ, UPDATE, and DELETE operations as well
Currently, we have a semantic schema for
identifiers
which allows a type to define more than one set of identifiers, where each set is either a single JSONPointer to a property, or an ordered list of JSONPointers to multiple properties, where a unique identifier is formed as a composite key.Generally this is fine, but it would make usage clearer for some caller scenarios if a single identifier (single property, or composite key) was defined as the primary identifier. This identifier should globally, uniquely identify an instance of the modeled resource and can be relied on to never change for the life of a resource. This would also require that the CloudFormation registry ensure that primary identifiers cannot change for a published resource type once defined.
We also want to allow additional identifiers which can be used as inputs to READ operations, in order to cater for multiple external systems which may be relying on a different form of identifier, such as using an S3 Bucket ARN rather than an S3 BucketName. If a provider chose to support additionalIdentifiers, the requirement on those would be that a READ operation should be able to use those identifiers to fully describe a model, including its primary identifier. This is unchanged from the current schema contract.
additionalIdentifiers
would be offered for improved user-experience for callers, and would not be subject to ongoing limitations. They can be re-ordered, removed, changed, etc for each published version of a resource type. As long as the READ handler for that type meets the contract, theadditionalIdentifiers
would be valid for that version.The proposed schema change I have is;