Add support for more data type - #13
Open
Aryan1296 wants to merge 2 commits into
Open
Conversation
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.
Feat: Add Support for Custom and Enum Data Types
This pull request resolves issue #1 by introducing robust support for user-defined custom data types, including PostgreSQL ENUMs. This enhancement empowers users to model their databases with greater accuracy and flexibility, accommodating a much wider range of data types directly within the DrawDB interface.
Problem
Previously, DrawDB was limited to a predefined list of data types. This was a significant constraint for users who rely on powerful PostgreSQL features like enumerated types (ENUM) or specialized types provided by extensions (e.g., ULID). The inability to specify these types meant that database diagrams were often incomplete or required manual workarounds, complicating the development process.
Solution
Instead of adding new types on a case-by-case basis, this implementation adds a dynamic, user-driven solution. Users can now add custom data types directly within the column's user interface.
This approach provides two key benefits:
Immediate Support for ENUMs: Users can now define columns with ENUM types as they would in a standard PostgreSQL schema.
Future-Proof Flexibility: The platform can now handle any custom data type from PostgreSQL plugins or user-defined types without needing further updates from the DrawDB team.
Key Changes:
Enhanced UI: The "Data Type" field in the column editor now allows for free-text input, enabling users to specify any custom type.
Schema Accuracy: The generated diagrams and scripts will now correctly reflect the use of ENUMs and other custom types.
Improved Developer Workflow: Eliminates the need for workarounds and ensures that the visual model in DrawDB is a true representation of the database schema.