Closed francktrouillez closed 7 months ago
You could also disable the cop locally using comments, see: https://docs.rubocop.org/rubocop/1.62/configuration.html#disabling-cops-within-source-code
You could also disable the cop locally using comments, see: https://docs.rubocop.org/rubocop/1.62/configuration.html#disabling-cops-within-source-code
Yes, that was also a possibility! Thanks for pointing that out! I think updating the message is still a good idea, as it is more explicit about what's expected and doesn't enforce "wrong" implementation in some situation (like the one in this PR).
I got the cop
RuboCop(Sequel/ConcurrentIndex)
complaining when I'm trying to run a migration to create/drop an index on a partitioned table in PostgreSQL whenconcurrently: true
is not set, while it is currently not possible in PostgreSQL.Steps to reproduce
concurrently: true
RuboCop(Sequel/ConcurrentIndex)
is complainingconcurrently: true
Expected behavior
The cop should not complain, as the proposed change is not working for partitioned table in PostgreSQL
Actual behavior
The cop is complaining, forcing me to change to a non-working solution where a
Sequel::DatabaseError: PG::FeatureNotSupported
is raised.Proposed change
If this situation is still happening with up-to-date gems and ruby versions, I believe we could go in 2 directions:
concurrently
, even if it is set tofalse
, and change the message from'Prefer creating or dropping new index concurrently'
to'Specify
concurrentlyoption when creating or dropping an index.
I'm more in favor of the second option of keeping the cop but forcing it to say we should specify the
concurrently
option, instead of setting it totrue
, but I'm open for suggestions!I've opened a PR for this if it makes sense.
System configuration
rubocop-sequel version: 0.3.4
sequel version: 5.76.0
pg version: 1.5.4
Ruby version: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]