-
Couldn't load subscription status.
- Fork 11
correct logic for table name #10
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
correct logic for table name #10
Conversation
56e68a2 to
a76e5d5
Compare
@eahefnawy Also, please can you merge #9 in as well. Preferably, merge this first, and then #9
a76e5d5 to
0ffd21e
Compare
0ffd21e to
5184412
Compare
@barrysteyn You can use the generated table name in your application code. This component outputs the name of the generated table, which you can use as an input to another component. Example:
name: example-project dynamo: component: '@serverless/aws-dynamodb' inputs: name: table-name attributeDefinitions: - AttributeName: PK AttributeType: S - AttributeName: SK AttributeType: S keySchema: - AttributeName: PK KeyType: HASH - AttributeName: SK KeyType: RANGE region: us-east-1 function: component: ./code inputs: dbName: ${dynamo.name} dbArn: ${dynamo.arn}
@barrysteyn You can use the generated table name in your application code. This component outputs the name of the generated table, which you can use as an input to another component.
What you have described is different. You are describing using component inputs in other components. However, I am talking about the actual code that a user would use the component to deploy and run. Sure, if that component is aware of the table name, it could then pass it to the app code. However this is not very generic.
A good example is the amazing next.js component: It does not care about dynamodb (nor should it), since a user should be able to use whatever storage they desire (e.g. MongoDB). And so that component would never inject the name of the table into the app code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the super late response here @barrysteyn ... I think this change is good to go, I was just nervous of making changes to the table name as it's usually destructive, but it seems that you're handling it pretty well.
LGTM
Uh oh!
There was an error while loading. Please reload this page.
Table names must always be deterministic - if a name is defined, then it MUST not be random since it is probably designed to be used in application code.
This fixes logic in #4 and addresses #6. @dodgeblaster Please look at this over. I have done the following:
setTableName, and added comment (now easy to understand what's happening).nameInputstate variable (less state means less errors).In summary: this PR accomplishes what was set out to achieve in #4, but neatens up the logic and allows for a deterministic (i.e. non-random) table name if name is defined.
I can't stress how important it is that this PR be addressed.
Please @eahefnawy can you look at it right away. The logic is right now broken. Why? Because if I define a table name in this component, I can't refer to it in code since the name becomes random. This becomes a bigger problem when you have multiple instances of the same component (i.e. a prod and staging component), and so one needs the name to be deterministic so that you don't write special logic in each case to get to the table name.
Lastly, @danielcondemarin also needs this logic for the global table component.