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
Is your feature request related to a problem? Please describe.
It would be ideal if it was possible to have a versioned folder with multiple subfolders that could be tracked separately from a versioning standpoint. For example, it'd be great to be able to have separate tables, functions, and procedures folders that could be tracked separately, but in the same history table, without the version numbers colliding. Currently, it appears that the recommended approach for using the versioned folder is to have all of the versioned database objects in one folder, which does not allow you to organize your versioned objects in any meaningful way in your repository. Additionally, being able to force the deployment process to build your tables before functions and procedures for example, would be a huge help in making sure all dependencies are covered as the objects are built up.
Describe the solution you'd like
Add a versioned folder deployment sequence to the SchemaChange config that can be adjusted by the user. Add another column to the SchemaChange history table for the versioned source folder to disambiguate overlapping versioned numbers across subfolders while deploying the database objects.
Describe alternatives you've considered
I am currently using multiple SchemaChange configs in order to track database objects from separate versioned folders in different SchemaChange history tables. That setup allows me to reuse versioned numbers across different database object types and control the deployment order more easily. This solution is working, but I feel this is significantly harder to maintain than if this was implemented the way I am proposing.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
It would be ideal if it was possible to have a versioned folder with multiple subfolders that could be tracked separately from a versioning standpoint. For example, it'd be great to be able to have separate tables, functions, and procedures folders that could be tracked separately, but in the same history table, without the version numbers colliding. Currently, it appears that the recommended approach for using the versioned folder is to have all of the versioned database objects in one folder, which does not allow you to organize your versioned objects in any meaningful way in your repository. Additionally, being able to force the deployment process to build your tables before functions and procedures for example, would be a huge help in making sure all dependencies are covered as the objects are built up.
Describe the solution you'd like
Add a versioned folder deployment sequence to the SchemaChange config that can be adjusted by the user. Add another column to the SchemaChange history table for the versioned source folder to disambiguate overlapping versioned numbers across subfolders while deploying the database objects.
Describe alternatives you've considered
I am currently using multiple SchemaChange configs in order to track database objects from separate versioned folders in different SchemaChange history tables. That setup allows me to reuse versioned numbers across different database object types and control the deployment order more easily. This solution is working, but I feel this is significantly harder to maintain than if this was implemented the way I am proposing.
Additional context
N/A
The text was updated successfully, but these errors were encountered: