SST Dynamo Question, if you have a failed deploy, or maybe delete a stack from the AWS console then go to redeploy with SST it will not happen as it throws a

table already exists

error. Does SST have anyway to help with this? Maybe not failing but using the table instead? I guess I worry about down the road, a year from now if something gets messed up, we blow away a stack and redeploy we will have a lot of data in dyanmo. Won't be as simple as delete the table and redeploy.

that’s a good question, I would like to know if it’s possible to handle that failure by using the table instead of just throwing an error. however, I think for your case the best way to not loose the data would be • create a copy of your table (let’s call it

temp-table

) • delete the old one • deploy the new one through SST • copy data from the

temp-table

to the new one I have a lambda that does that, if you think it’s a good solution - and it’s made with SST 😄 https://github.com/carlosdnba/copy-ddb-table

Yeah that makes sense, I would like to think copying all the data would be a emergency last resort though. 🤷‍♂️ I have been thinking maybe I'll move my organization round a bit. I am not sure how folks generally organize stacks but I originally started by grouping together project concepts. Like maybe I have an stack that handles auth and another that handles application backend logic. So again grouped by project. However now I am thinking maybe it is better to group by AWS concept For example a DataStack for tables, and APIStack for Api's and a AppStack for static sites. I am thinking this way will simplify Stack to Stack sharing of variables as well as have the benefit of isolating my data from other stacks. So If i did need to blow everything away it would be everything but the DataStack. Seeing that there are only tables in the DataStack it is less likely to get mucked up over time. Any Thoughts?

I think it makes sense! it's what I've been doing recently (but I'm still studying). I have a StorageStack that contains tables and buckets if necessary, and another stacks for website or api as you mentioned

Yup I just moved the project I am working on now to this structure. Already feeling better about this. Essentially use stacks to isolate what's destroyable, then other stacks can be more project/implementation specific.

great

@Ross Gerbasi I tend to set the removal policy to

DESTROY

for non-prod stages. So i can blow them away and not leaving any dangling resources in the account.

@Frank Couple questions on that. I found myself wanting to do stuff in prod/staging only, what is the recommend check. Just if

stage === 'production' || stage === 'staging'

or do you use an ENV variable like

PERSIST_DYNAMODB

? Secondly, if you do not do this in production and do not separate your data into another stack, what do you do if you nee to blow away production in an emergency? How do you re-link the ddb to your stacks that need it?