-
-
Notifications
You must be signed in to change notification settings - Fork 263
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
Rails/UniqueValidationWithoutIndex should not fail when using scope #231
Comments
RuboCop Rails 2.5.2 has an expected tests for
|
Thank you showing code. This issue seems to be the expected behavior, not a bug.
In this case, it is expected that the following unique index is generated in db/schema.rb. t.index ["field_1", "field_2"], name: "idx_field_1_field_2", unique: true |
Thanks for the explanation. Would it be possible for the cop to give a more specific message? I thought I already had an index, but didn’t realize it was incorrect. |
Yeah, the offense message can be changed. On the other hand, offense messages are preferably simple, concise and short explanation. I'm not getting a good message yet. Do you have any good explanation? |
I don’t really know how to describe that syntax. Perhaps the error could just have a one-line code example of what’s expected in the model. |
@koic , I have same problem for scope with polymorphic belongs_to :fieldable, polymorphic: true I tried to add index with these migrations (with and without name options) last version of schema |
this is happening for me as well. model: validates :name, presence: true, uniqueness: { scope: :author } schema: create_table "apps", force: :cascade do |t|
t.string "name", null: false
t.string "author_type", null: false
t.bigint "author_id", null: false
t.citext "authentication_token", null: false
t.integer "failed_attempts", default: 0, null: false
t.citext "unlock_token"
t.datetime "locked_at"
t.integer "sign_in_count", default: 0, null: false
t.datetime "current_sign_in_at"
t.datetime "last_sign_in_at"
t.inet "current_sign_in_ip"
t.inet "last_sign_in_ip"
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
t.index ["author_id", "author_type", "name"], name: "index_apps_on_author_id_and_author_type_and_name", unique: true
t.index ["author_type", "author_id"], name: "index_apps_on_author_type_and_author_id"
end It seems like maybe the cop isn't checking for model: validates :name, presence: true, uniqueness: { scope: :version } schema: create_table "docs", force: :cascade do |t|
t.bigint "version_id"
t.string "name", null: false
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
t.index ["name", "version_id"], name: "index_docs_on_name_and_version_id", unique: true
t.index ["name"], name: "index_docs_on_name"
t.index ["version_id"], name: "index_docs_on_version_id"
end |
The same problem :( model:
migration:
|
I had to disable this cop for the following code: Schema: create_table "time_slot_bookings", force: :cascade do |t|
t.string "state", default: "pending"
t.index ["state", "published_time_slot_id"], name: "index_time_slot_bookings_on_state_and_published_time_slot_id"
… Validation: validates :state, uniqueness: { scope: :published_time_slot_id,
conditions: -> { processed },
message: 'should not be double booked' } While I see that an index makes sense in general, uniqueness on the database is not possible in this case (without manually writing SQL). |
Hi! I'm still running into this issue... Gems: Model: Schema: Is there an underlying fix for this issue besides silencing Rubocop? |
We can probably improve the handling of scopes/polymorphic associations/etc in the rubocop itself (unfortunately by introducing more and more complexity into it), but there is already a tool better suited for such checks and more - https://github.com/gregnavis/active_record_doctor. It has a check for missing unique indexes - https://github.com/gregnavis/active_record_doctor#detecting-uniqueness-validations-not-backed-by-an-index and handles all the mentioned problematic cases. |
Desabilitado cop Rails/UniqueValidationWithoutIndex pois continua apontando falha mesmo depois de incluir índice de unicidade no banco de dados. Problema é comum conforme rubocop/rubocop-rails#231
We're still having this issue in our project as well. We used three methods to verify that the index has taken effect and decided to temporarily ignore the Gems
Model validationvalidates :feature_type, presence: true, uniqueness: { scope: [:product_featureable_type, :product_featureable_id] } Schemacreate_table "product_features", id: :uuid, default: -> { "gen_random_uuid()" }, force: :cascade do |t|
t.string "product_featureable_type", null: false
t.uuid "product_featureable_id", null: false
...
t.string "feature_type"
t.index ["feature_type", "product_featureable_type", "product_featureable_id"], name: "index_on_feature_type_and_product_featureable", unique: true
t.index ["product_featureable_type", "product_featureable_id"], name: "index_product_features_on_product_featureable"
end Verification1. Verify the index exists in the database
2. Use active_record_doctor gem to identify whether the issue exists.Before: Try removing one of the columns in the scope.validates :feature_type, presence: true, uniqueness: { scope: [:product_featureable_id] }
After: Use the full scope that we want.validates :feature_type, presence: true, uniqueness: { scope: [:product_featureable_type, :product_featureable_id] }
We expect the message below to be listed, but it isn't. This indicates that the unique index has been added.
3. Create records manually in Rails consoleThe validation took effect and the transaction rollback as expected. |
A uniqueness validation over a scope should not fail
Rails/UniqueValidationWithoutIndex
, as a unique index would not necessarily be unique for the entire table when it's unique under the scope.Expected behavior
Cop should not fail when a scope is used to prevent false positives and not encourage the user to change their schema in a way that could break scoped uniqueness functionality.
Actual behavior
Steps to reproduce the problem
RuboCop version
The text was updated successfully, but these errors were encountered: