You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The solution is most likely to break components out and only run the dynamodb component deployment once. However what happens in this case when the database is to be expanded?
The text was updated successfully, but these errors were encountered:
The sense I got from going through the previous thread is that:
As you said, separating components and using Fn::ImportValue to grab the relevant information from the separate stack is recommended.
When the DB needs to get expanded, you will have manual work to do exporting the data / reimporting it, as you'll still have to delete the existing table for the sls deploy to work on your db stack.
Some users seem to have found workarounds with Ansible / Terraform
So all in all, there doesn't seem to be a path forward using a pure serverless solution for this based on the rationale for closing the issue you linked: serverless/serverless#3183 (comment)
I'm on board with that logic, I just wish these limitations were more clearly stated before we commited on serverless with our project so we could plan for them a bit better
If the dynamodb table already exists the deployment can not be run.
This issue here summaries the problem and frustrations well
serverless/serverless#3183
The solution is most likely to break components out and only run the dynamodb component deployment once. However what happens in this case when the database is to be expanded?
The text was updated successfully, but these errors were encountered: