-
Notifications
You must be signed in to change notification settings - Fork 128
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
Fails with wrong number of arguments when used inside a subclass in Ruby 2.6+ #84
Comments
Thanks for your contribution. I just recently started helping to maintain this gem. Is this still an issue? Note, we dropped support for rubies less than 3.0 in 4.0. Version 3.6.x supports rubies less than 3.0. Please open if there is still a related issue in master with ruby 3.0-3.3. Thanks! |
Thanks for merging this; we've been using my commit/patch for several years now without issue. I'm not sure if is still an issue, though I suspect this fix still works. When jumping to Rails 7.2 the built-in ActiveRecord 'attribute' method can now do much of what this gem does; as you can finally set a default value for an attribute without also needing to provide the data type: # Rails 7.2+
attribute :foo, default: 'bar'
attribute :serialnumber, default: -> { SecureRandom.uuid } In Rails 7.1 or prior this was more difficult to use for this purpose because you had to provide the data type, rather than letting it detect it from the DB schema. |
Thanks, I didn't merge it yet. I'll try to better understand if we can add it. Yes, the attribute api handles a lot of the basics of this gem. Where it's lacking is masking "changed?" and deriving defaults based on an instance of the object, namely, the block notation. I'll reopen this and see if I can figure out if the change is still needed. Thanks for the information. |
If using
default_value_for
within a subclass of another model, then the class instance initialization will fail with:ArgumentError (wrong number of arguments (given 2, expected 0..1))
This is version 3.3.0 and using all combinations of Ruby 2.6.5 and 2.7, and with Rails 5.2 and 6.0.
For example consider the classes:
Then calling
Example.new
will abort with the error. If on the other hand that were to subclass directly fromActiveRecord::Base
instead ofApplicationRecord
then it works fine.I think I've tracked it down to calling
super()
within theinitialize
method. If I replacethe code in
default_value_for.rb
with
then it seems to work fine. Though I am not comfortable that this is the correct change to make.
The text was updated successfully, but these errors were encountered: