Ruby 3 compatibility about database_cleaner HOT 9 OPEN

@swiknaba Not sure about Micah's preference, but I would prefer the options-hash way.

So instead of doing this:

    def strategy=(args)
      strategy, *strategy_args = args

I would be interested in it doing this:

    def strategy=(strategy, strategy_args = {})
      ...

I think that would be the least disruptive change and it wouldn't require people using database_cleaner to change their implementations.

from database_cleaner.

@swiknaba @etagwerker Yes, options-hash sounds good to me!

from database_cleaner.

In the case that helps, here is the deprecation warning from Ruby 2.7 :

/usr/local/bundle/gems/database_cleaner-core-2.0.1/lib/database_cleaner/cleaner.rb:85: warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call

from database_cleaner.

@botandrose in case one would start working on this, any preference from the maintainers for either kwargs or options-hashes? I think, using hashes gives more flexibility regarding the DSL, since the gem is broken into multiple gems, and each gem might want to add or omit certain options/key-words. On the other hand, being explicit makes it easier to follow the codebase if you are not familiar with it. From my short look at two of the gems (Redis, active-record), there are not that many options, thus being explicit could be the way to go.

from database_cleaner.

@swiknaba @etagwerker I took a look at this today, and I learned something new about Ruby! It looks like the way Ruby handles multiple arguments to setter methods ending in = is a bit of syntax sugar magic. Specifically, it will always first convert the multiple arguments to an array, and then passes that array as a single argument to the method. The only way I could find to bypass this magic is by using send:

DatabaseCleaner.send(:strategy=, :truncation, { only: "users" })

Therefore, in order to keep the same API, we appear to be stuck with the def strategy=(args); strategy, *strategy_args = args; ... pattern. @swiknaba You say in your original post that this won't work on Ruby 3.0, but the tests are all passing, and I wasn't able to reproduce the failure locally. Can you explain what you mean? At present, this implementation doesn't seem to be a problem.

I do agree that we should normalize options hashes vs kwargs across the DatabaseCleaner gem family.

from database_cleaner.

Ruby 3.0 is out since almost 2 years now, when could we expect this gem to be adapted for Ruby 3 ?

@botandrose which branch has that fix ? If I can help by testing it, I would be very happy to do so.

from database_cleaner.

@botandrose indeed, tests are all passing, however when I used

DatabaseCleaner.strategy = :deletion, { except: %i[not_you also_not_you blubb] }

in my codebase, then RSpec failed with a syntax error.

It seems there was a workaround found: DatabaseCleaner/database_cleaner-mongoid#16 (comment)

I haven't tested that yet, though.

from database_cleaner.

Even though CI seems to pass, for me running Ruby 3.0.3 against v2.01 locally raises two errors:

In any event, I ran into the same issue as others, and circumvented it by specifying the strategy object explicitly:

DatabaseCleaner[:redis].strategy = DatabaseCleaner::Redis::Deletion.new(only: ["something:*"])

This approach is documented in the ActiveRecord adapter, but isn't present on this specific repository and other adapter repositories.

Is an easy solution to this problem adjusting the documentation to recommend the above approach? Anyone upgrading who runs into this issue will likely revisit the docs and can correct the problem easily. Downside is that it smells like a bit of an abstraction leak. If there is a desire to keep using primitive values to set a strategy, then I think the strategy= should be deprecated in favor of something like set_strategy(strategy, strategy_args = {}), similar to how @etagwerker suggested.

from database_cleaner.