-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
ForeignKeyTypeChecker duplicates #146
Comments
Hi @pirj , Thank you for reporting this! Could you please help me to understand what you think we should do instead? I see it this way: every About the combination of P.S. I guess more "noise" makes people fix it quickly or do you think it's better to reduce it? |
Hey @djezzzl ! 👋 In the first case, it's a one-to-many. ForeignKeyTypeChecker fail Line report foreign key (report_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Report lines foreign key (report_id) with type (integer) doesn't cover primary key (id) with type (bigint) The
For polymorphic associations it's mire complicated, as some associated tables may have the same key type, and some - a bigger one. create_table "bars", force: :cascade do |t| # bigint! too big for `item_id`
# ...
end
create_table "bazs", id: :serial, force: :cascade do |t| # integer
# ...
end No good ideas how to behave in this case. Show it ust for those that are not covered? ForeignKeyTypeChecker fail Foo versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Bar versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
ForeignKeyTypeChecker fail Baz versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
I don't have a strong opinion here. It may deter people from fixing if the task looks like it needs more effort. |
Hi @pirj , I've just released 1.3.6 with the improvement. Could you please have a look and say if that's any better? Feel free to reopen the issue if needed and I wish you a good weekend. |
Thank you, @djezzzl At a glance, there might be a regression that swallows some cases, as the list of A random example of what went missing:
The ones with ForeignKeyTypeChecker fail Foo versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Bar versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Baz versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint) instead of: ForeignKeyTypeChecker fail Foo versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Bar versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
ForeignKeyTypeChecker fail Baz versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint) Please let me know if you need more. |
Could you please share the before output and after? Without that, unfortunately, I can't say if that's expected or not.
Why it should be collapsed only to two cases rather than to a single one? As soon as |
One association is picked while others are hidden. |
And what should we do in this case? I don't think that we should be too smart on this one and anyhow analyze the persisted data amount. What do you think? Looking at this now, I think when we remove duplicates, we may highlight how many offenses we grouped. What do you think a good message would look like in this case? |
If it could list the offending tables that were collapsed, that would be sufficient: - ForeignKeyTypeChecker fail Foo versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Bar versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
- ForeignKeyTypeChecker fail Baz versions foreign key (item_id) with type (integer) doesn't cover primary key (id) with type (bigint)
+ ForeignKeyTypeChecker fail (Models Foo, Baz) versions foreign key item_id with type integer doesn't cover primary key id with type bigint Indeed, we can't have an idea of the number of production records when running |
Could you please help me understand why you're missing I like listing all the models. BTW, have you found more missing cases? |
As in the example above, one of those tables has an |
Extended output is on the way: #150. |
ForeignKeyTypeChecker
seems to report the same problem twice (or more for e.g. polymorphic associations).paper_trail
)The text was updated successfully, but these errors were encountered: