Skip to content
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

Track version numbers across different versioned subfolders and orchestrate their deployment #277

Open
CalculusAce opened this issue Aug 13, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@CalculusAce
Copy link

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

@CalculusAce CalculusAce added the enhancement New feature or request label Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant