Problem replacing the production database
Hello guys, I am trying to restore a backup from one of my dev branches into the production one (I did many many updates to the schema) therefore I get a lot of errors like:
Hit an error while importing: Failed to insert or update a document in table "subscriptionPlans" because it does not match the schema
The problem is I can't even deploy the new schema because it conflict with the current database content in the Production db.
How is it damn possible that there is no option to delete the whole db???? Can you please do it for me or something, otherwise I can't deploy in any way....
Let me know asap I need to deploy this update in production.
Regards.
7 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
Can someone answer this please/
That's an interesting point, and its because usually production tables shouldn't be touched, like ever, because they contain user's information, and probably valuable data, and would cause some security vulnerabilities if you kept it easy to delete like that.
there's about two to three stack flow posts about this teaching us how do migrations, one of which is:
https://stack.convex.dev/migrating-data-with-mutations
and there's also videos by jamie, he explains it a bit better on how to do this with/out the component https://stack.convex.dev/zero-downtime-migrations
I can't find this on stack, but I seriously suggest watching the video and reading the stack post above. for future questions, make sure to have your question in a better format, with minimal code examples to be exact, it would help us and yourself. Tl;dr would be nice.
if someone access the account the last worry would be deleting stuff
How do you not see the problem?
in the current prod I have all stuff I don't need anymore, migrations are completely uselss in this case
only one is deleting the content of the prod 1 by 1 for each table, which is just un-practical, is not hard to just add an option to do all tables at once, whyn you have 40-50 table is not that nice to do it one by one
Run this in the cli to delete your prod data
What Sara's trying to help you understand is, while it may be tenable for you to just delete prod today, in the future when you have real users and real data, you probably won't have that option. Schema changes require forethought, planning, and migration steps, no matter what database you use.