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
At my work, we are a few steps away to start using grate for the first time in our production databases. Everything looks good, but we only have one issue. The databases that we are starting to version are existing once that are close if not over 15 year old. We are starting to use grate because we are expanding the database for the first time in years, and we want to track the changes now.
However, I would like to add everything to our grate system like all stored procedure and eventually all the tables. To do this we can of cause use the --baseline command to add any such items. The complication comes with the grate.version table. We technically are at version 10.5 something, but the old tables where implemented long before that at essentially version 1.0. During experimentation, I have seen that if I add a baseline script like 4.7, then grate will add the new version with a new version ID that is incremented which makes sense. However, if I then add migration like 10.6 and run it then I will have a version history that displays 10.5->4,7->10.6. While this will work, its not the most pretty solution. Just like up scripts, can I adjust the version Id of grate to "order" the scripts or is this just bad practice and I should just accept that due to the version was applied late, this is just how it is now?
Or is there other tactics I can use to prevent this. Technically, I have the same problem with my git repository system.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
At my work, we are a few steps away to start using grate for the first time in our production databases. Everything looks good, but we only have one issue. The databases that we are starting to version are existing once that are close if not over 15 year old. We are starting to use grate because we are expanding the database for the first time in years, and we want to track the changes now.
However, I would like to add everything to our grate system like all stored procedure and eventually all the tables. To do this we can of cause use the
--baseline
command to add any such items. The complication comes with thegrate.version
table. We technically are at version 10.5 something, but the old tables where implemented long before that at essentially version1.0
. During experimentation, I have seen that if I add a baseline script like4.7
, then grate will add the new version with a new version ID that is incremented which makes sense. However, if I then add migration like10.6
and run it then I will have a version history that displays10.5
->4,7
->10.6
. While this will work, its not the most pretty solution. Just likeup
scripts, can I adjust the version Id of grate to "order" the scripts or is this just bad practice and I should just accept that due to the version was applied late, this is just how it is now?Or is there other tactics I can use to prevent this. Technically, I have the same problem with my git repository system.
Beta Was this translation helpful? Give feedback.
All reactions