Add configurable default conversion type for non-native Pascal field types#1
Open
Stepwier wants to merge 1 commit into
Open
Add configurable default conversion type for non-native Pascal field types#1Stepwier wants to merge 1 commit into
Stepwier wants to merge 1 commit into
Conversation
…l types (variant, integer, string). The variant type is selected by default to maintain compatibility with previous versions of DataModeler.
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
1 participant
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.
Description
This PR introduces a new option in DataModeler Aurelius to define a default conversion type for non-native Pascal field types, such as MySQL ENUM fields.
Problem Statement
Previously, when the DataModeler encountered database field types that do not have a direct Pascal equivalent (e.g., MySQL ENUM), these fields were treated as computed and generated using the Variant type by default.
While this allowed the generated unit to compile successfully, it led to runtime issues, including crashes due to unresolved or unsupported type handling (“unknown type”).
Solution
A new configuration option has been added allowing users to explicitly define the default conversion type used for such fields.
Supported conversion targets include:
This enables better control over generated models and avoids runtime instability caused by inappropriate type mappings.
Behavior Changes
✅ Non-native types (e.g. MySQL ENUM) can now be mapped to a user-selected Pascal type.
✅ Generated code is safer and more predictable at runtime.
✅ Users can align generated models with actual database semantics.
Backward Compatibility
The default behavior remains unchanged: Variant continues to be used if no option is specified.
Existing projects will not be impacted unless the new option is explicitly configured.
Example
Before:
property Status: Variant; ....
After (with String mapping):
property Status: string; ...
Impact & Benefits
Eliminates runtime crashes caused by invalid Variant usage in certain DB mappings
Improves type safety and clarity in generated models
Gives developers explicit control over mapping strategy
Enhances compatibility with MySQL-specific data types
Testing
Verified code generation for MySQL ENUM fields
Tested mappings for all supported types (Variant, Integer, String)
Confirmed successful compilation and runtime behavior
Notes
This change primarily targets MySQL users but applies to any non-native database field type handled as computed by the engine.