Is it possible to stop supertokens-core from autom...
# support-questions-legacy
n
Is it possible to stop supertokens-core from automatically creating SQL tables via an environment variable? We would prefer to run the DB migrations with our own migrations runner.
r
Hey @n1ru4l there is no way to do this. The best thing would be to create the tables beforehand and then start the core. Our schema can be found in our docs in the getting started section -> core -> self hosted part
n
Would you accept a PR that adds a environment variable for preventing the table creation?
r
Yea sure. Would accept it. It should be a config on the core.yaml, just like the other configs.
The thing is though if the tables aren’t there, the core can’t really successfully start
So you would have to create the tables before (which you can do now too). And then the core doesn’t attempt to create the tables anyway, cause they already exist.
Am I missing a use case here?
n
we want to control the database migration via our database migration scripts which we already use for everything else. When we apply major upgrades for supertoken-core, we run these script via our migration runner. When people develop locally we sometime have issues where people first start supertokens, then run database migrations, which then also attempt running supertokens migration code, which then partially fail and leave the database in a state where you then need to delete it, recreate it, run the migrations again and then supertokens. It is probably not a big deal, but it caused a lot of confusion before when onboarding new team members to our project.
r
ahh i see. So the issue is that if you start the newer version of the core first before running your migration script (which is what you described above), the core startup may fail.
so disallowing the core from creating the new required tables won't solve the problem anyway
n
core failing before migrations are run is okay for me (even if I wonder why the core was not developed in a way where it can be backwards-compatible with before and after db migration, but I can see that this might be too much hassle vs just having a small down-time) The problem is mainly having race conditions between starting supertokens and running database migrations. But, this discussion made me wonder whether it is just a documentation/communication issue on our end 🤔 .
r
yea, if you ask your team memebers to run the migration script before starting the new core, that would work
ideally, the core should do all the migrations needed on it's own anyway, but until that's implemented, this is how it works. I'd be happy to accept a PR regardless, since i think a similar request bhad come before too.