3 ms·
Sorta. Creation is only easy if you know what the expected state is. Did you just create a new table, or was it already created? This is especially hard when
by taeric 4y ago
Sorta. Creation is only easy if you know what the expected state is. Did you just create a new table, or was it already created? This is especially hard when you /want/ table names that are not stable.
- jakelazaroff 4y agoYou mean with regard to renaming, right? If your database has table `foo` and your config has table `bar`, did you mean to create a new table `bar` or rename your existing table `foo` to `bar`?
- taeric 4y agoThat, but also just managing that I want a stack to create a new table that I will logically refer to as "foo" in the stack. Outside the stack, I actually /don't/ want anyone referencing the table. Such that I expect the physical name to have a guid or some such. If you do that, it /has/ to keep track of which table it created, versus which were already there. (Right?)
- nathants 4y agousing names to uniquely identify infrastructure is very convenient and how most of aws already works. why not take advantage of that instead mapping name to uuid via state? in what scenario are non-stable infrastructure names useful?
- taeric 4y agoIf you are using cloud formation, it already does a uuid like name on resources it creates.
- nathants 4y agoi’m not. i do my own thing[1] with the go sdk. 1. https://github.com/nathants/libaws https://github.com/nathants/libaws
- jen20 4y agoIt certainly isn’t how “most” of AWS works. Nothing makes the name tags for important APIs like VPC or EC2 even exist, yet alone be unique. They use provider-assigned IDs instead.
- nathants 4y agovpc and ec2 are the big ones. they both support tagging atomically during create though, so it’s fine? for ec2 i’m not sure i’d want unique names per instance. typically i prefer groups of instances with the same name.