-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the SchemaVersions location to another instance #127
Comments
Hello, thanks for the feature idea. |
Hi, unfortunately I mean the second one. Discovered this solves an issue with Azure Synapse Analytics and I think a few people would prefer it if they could change the table to be in a separate SQL database. |
There are two major issues related to this functionality:
Have you seen, by any chance, a working solution that I could look at? Maybe the problem isn't as big as I'm imagining. |
Apologies for the delay. I have not seen a working version of it. Only a couple of references online saying how it can be done in theory. |
For me, it's important to keep the SchemaVersions (migration log) table in the target DB so it can follow it along if it is copied/moved somewhere. I could see some benefit to ALSO having it log to another central DB on the same or another instance, though. |
If you want to use it with serverless SQL Pools then only option is to have be able to specify another location. |
Ah. Of course. Actually working with an external table or view (ie files) in serverless SQL would be a pretty tricky endeavor indeed. Not impossible, but definitely not simple like a "regular" RW SQL table. Thanks for clarifying, Kevin. |
I've seen some discussions online about various attempts by others to move the SchemaVersions table to another location using DbUp. It would be great if this was possible with this module.
The text was updated successfully, but these errors were encountered: