Timeline for How to do versioning for stored procedure?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 19, 2024 at 12:53 | comment | added | theking2 | In addition to David's excellent answer In your case the stored procedures can considered part of the API. Hence if there is a new version of the API which is not compatible than your software as well as your stored procedures need to follow suite. Apart from that versioning a (REST?) API is a bad think in itself for much the same reasons as David pointed out: an extra code base needs to be maintained. Consider making your API HOTEOAS and have clients automatically adapt newer versions (contracts) of your API | |
| Aug 6, 2019 at 17:02 | comment | added | Blrfl | @Shanid If the development database is being treated as a gold copy and can't be rebuilt into the same state from scratch, it would be wise to stop what you're doing and reconsider your development processes. | |
| Aug 6, 2019 at 12:53 | comment | added | Shanid | Unfortunately, some procedures have already been modified in the development environment. What can be done in that case ? Is there any way to handle this such that we do not need to change the procedure name ? For example, like changing schemas of procedures, is there any such way ? | |
| Aug 6, 2019 at 12:07 | history | answered | David Arno | CC BY-SA 4.0 |