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
{{ message }}
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.
Is that possible/feasible? We're having trouble sensibly creating rollback scripts for SP changes (which our suite of applications relies on heavily). Any advice for that?
Not sure if it is feasible or not, but it would be very slick!
I prefer to keep my Stored Procs in separate files, 1 file per sproc - just as if they were code classes.
A newish plugin in dotnetmigrations-contrib is PersistentMigrations (pmigrate command) that supports the concept of running certain script files during every migrate. So I end up having a /migrate folder for my schema migration scripts and a /sprocs folder for my stored procedure scripts. I've configured it such that my /sprocs scripts are run every time.
If needed I will also create a /views, /functions etc folder for other objects that I don't feel should be put in migration scripts.
I think that we should leave exactly how people want to use migrations up to them. I'm not certain that the "persistent" scenario would work well for some projects I've worked on for instance (1000s of SPs for better or for worse) - and just make people manage rollbacks for SPs by hand (its very rare).
I don't think other migration frameworks (my favourite being Flyway on Java) handle anything specially for SPs?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
No description provided.
The text was updated successfully, but these errors were encountered: