Commit for specifying global vs tenant statements#751
Merged
Conversation
zachdaniel
approved these changes
May 14, 2026
Contributor
|
🚀 Thank you for your contribution! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contributor checklist
Leave anything that you believe does not apply unchecked.
issue #538 proposed solution
Certain custom statements, specifically custom enum types, become part of the tenant migration and fail to execute as they create a duplicate table. This should instead become global for the database instead. Manual intervention was a workaround needed for this. The solution is to add a configuration.
DataLayer.md:
Line 199: provides documentation for the new configuration boolean.
statement.ex:
Line 13: Add the new configuration
Lines 35-41: Add the behavior for the configuration. This is set default to false to allow normal behavior and backwards compatibility.
migration_generator.ex:
Lines 513-577: Modified the tenant operations to still allow normal behavior with the new configuration, and then the configuration assists in deciding if the file should be sent to the tenant or have public access.
Lines 4313, 4344-4346: Edit the JSON storage of the custom statement to include the new configuration, this way it is not lost on storage and retrieval.