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.

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

Add metadata for AWS constructs are defined with a physical name #92

Closed
eladb opened this issue Jun 13, 2018 · 4 comments
Closed

Add metadata for AWS constructs are defined with a physical name #92

eladb opened this issue Jun 13, 2018 · 4 comments
Assignees
Labels
feature-request A feature should be added or improved.

Comments

@eladb
Copy link
Contributor

eladb commented Jun 13, 2018

When an AWS construct is defined with an explicit physical name, we'd like to annotate the construct with metadata that contains that physical name, so that tools and aspects will be able to reason about it. We have a few examples throughout the library which add the aws:cdk:hasPhysicalName metadata entry for physical names, but we should normalize this though a common library.

@jungseoklee
Copy link
Contributor

I am wondering how to normalize this.

I would like to solve a problem where we miss adding physical names to metadata. For example, DynamoDB and Kinesis L2 constructs add physical names to metadata, but SQS does not.

It is specific to service whether physical name is supported or not, so it seems tricky to handle it in a common library level.

@eladb
Copy link
Contributor Author

eladb commented Oct 14, 2018

There are two levels of "common" functionality:

  1. Just a a common utility function that L2s can call in order to report that an explicit physical name was used.
  2. Automatically-identify (e.g. through heuristics on the property names) that a physical name was used in L1.

I think all physical names are usually called Name or XxxName, so option #2 might actually be the pragmatic approach.

Perhaps this is also related somehow to #928 - maybe this utility will also supply some tools for L2s to make this easier to implement.

@jungseoklee
Copy link
Contributor

Thanks for the answers.

I agree with an idea of #928, which helps to achieve the option 2 here.

@srchase srchase added feature-request A feature should be added or improved. and removed enhancement labels Jan 3, 2019
@eladb eladb self-assigned this Aug 27, 2019
@eladb
Copy link
Contributor Author

eladb commented Oct 2, 2019

We will reopen if this is relevant in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

3 participants