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

Ensure matching column message when missing Enum #908

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

stan-slas
Copy link

First PR here πŸ‘‹

What

When we declare an Enum field in the models, it should be referenced as Int32 in the migration file (https://luckyframework.org/guides/database/models#using-enums).

The current message was instead suggesting to type it as Enum in the migration which doesn't work.

How it has been tested

  • Added one missing test for the missing column
  • Added the specific UT for the Enum case

I didn't assert the full message for brevity of UT on hint messages. I thought it may become too verbose for a not critical function but feel free to request if needed.

Example of full message

ModelWithMissingEnumColumn wants to use the column 'gender' but it does not exist.
Try adding the column to the table...
       
         β–Έ Generate a migration:
       
             lucky gen.migration AddGenderToModelWithMissingEnumColumns
       
         β–Έ Add the column to the migration:
       
             alter :users do
               # Add the column:
               add gender : Int32
       
               # Or if this is a column for a belongs_to relationship:
               add_belongs_to choices : Int32
             end
       
       Or, you can skip schema checks for this model:
       
           class ModelWithMissingEnumColumn < BaseModel
             # Great for models used in migrations, or for legacy schemas
             skip_schema_enforcer
           end

Copy link
Member

@jwoertink jwoertink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I think this will help for sure, but I have a few questions. I'm not sure if it's always been the case, but add_belongs_to choices : Int32 wouldn't ever make sense. This would assume Int32 has a id method that would relate back to choices_id. We may want to think about just putting something more generic there. Any ideas?

Also Enums can technically be Int64 as well. Maybe there's a way we can detect if the Enum type is Int64?

@@ -49,6 +49,8 @@ class Avram::SchemaEnforcer::EnsureMatchingColumns < Avram::SchemaEnforcer::Vali
if best_match
message += " Did you mean '#{best_match.colorize.yellow.bold}'?\n\n"
else
# Enum column are mapped to Int32 in the database layer
missing_attribute_type_hint = "#{missing_attribute[:name]} : #{missing_attribute[:type].sub("Enum", "Int32")}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice, but it's possible to define an Enum as Int64 as well. #856

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming back to this, we may eventually want to add all of the Int. Like if you had a Colors Enum that you wanted to be Int8 or maybe Int16. I'm not sure the best way to handle this just yet, but definitely having Int32 static in here may be an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants