Rails 7 support

[olegantonyan]

Is it already in progress? I had to change few things to make it work (kind of, not perfectly). But maybe a proper support is around the corner.

Also, a bit related, is there a chance for this PR to be merged? #53

[psdao1102]

@olegantonyan hey, do you know what needs to be changed? Im in a pickle because of this gem not being updated to 7. Id like to fork and make the changes myself but i don't understand the inner workings of active record.

[olegantonyan]

I use own fork https://github.com/olegantonyan/polymorphic_integer_type
You can see the diff here master...olegantonyan:polymorphic_integer_type:ruby-3-and-rails-7-support

But there is a problem with has_one association. Don't remember the details exactly, but I had to work around it. So if you end up going this route - test it thoroughly

[cmrd-senya]

Rails 7 has been supported since v3.2.0. However Rails 7.1 is not supported, the gemspec explicitly restricts the package to depend on Rails 7.0 and below.

@wendy-clio are there any plans to support Rails 7.1 ? What's the main issue with supporting Rails 7.1?

Rails 7.2 will be released soon too

[wendy-clio]

Rails 7 has been supported since v3.2.0. However Rails 7.1 is not supported, the gemspec explicitly restricts the package to depend on Rails 7.0 and below.

@wendy-clio are there any plans to support Rails 7.1 ? What's the main issue with supporting Rails 7.1?

Rails 7.2 will be released soon too

Although I haven't dug into it properly, I doubt there are many blockers to upgrading to Rails 7.1. The main problem is that the gem doesn't have an actual owner. Although I am happy to try upgrading the gem, I can only do it in my spare time. Unfortunately, that means I can't provide a solid timeline.
Also, if 7.2 is released soon, it may be worth waiting and upgrading directly.

Another point worth noting: AFAIK, this gem's primary usage is in our manage codebase, which is still on Rails 6.1. We won't gain much organizational benefit immediately.

[cmrd-senya]

@wendy-clio thanks for the update!

We might work on the support ourselves once we get close to upgrading from Rails 7.0 to 7.1, if it's not done by then. But I cannot yet tell regarding when we can get there.

If we prepare a PR for supporting Rails 7.1, can we expect it to be reviewed and accepted?

Is there anything special we may need to know to work on that?

[cmrd-senya]

We may explore support of 7.2 as a part of that too

[wendy-clio]

@wendy-clio thanks for the update!

We might work on the support ourselves once we get close to upgrading from Rails 7.0 to 7.1, if it's not done by then. But I cannot yet tell regarding when we can get there.

If we prepare a PR for supporting Rails 7.1, can we expect it to be reviewed and accepted?

Yes, for sure. I can help and most staff should be happy to review it.

Is there anything special we may need to know to work on that?

Not I can think of now.

[cmrd-senya]

Hello @wendy-clio !

I made some research on Rails 7.1 support with polymorphic_integer_type gem.

Here's what I've found.

There's one test that fails once Rails is set to 7.1 version.

Here's the test that fails:

Failures:

  1) PolymorphicIntegerType When a link is created through an association and the link is accessed through the associations should have the proper source
     Failure/Error: expect(source.source_links[0].source).to eql source
     
       expected: #<Animal id: 1, name: "Alexi", type: nil, kind: "Cat", owner_id: nil>
            got: nil
     
       (compared using eql?)
     # ./spec/polymorphic_integer_type_spec.rb:182:in `block (4 levels) in <top (required)>'
     # ./spec/spec_helper.rb:42:in `block (3 levels) in <top (required)>'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/transaction.rb:535:in `block in within_new_transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activesupport-7.1.3.4/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/transaction.rb:532:in `within_new_transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/database_statements.rb:344:in `transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/transactions.rb:212:in `transaction'
     # ./spec/spec_helper.rb:41:in `block (2 levels) in <top (required)>'

Finished in 4.21 seconds (files took 0.60888 seconds to load)
1 example, 1 failure

I've tracked down the change in Rails that is causing the failure.

The change is this line:
rails/rails@7b6720d#diff-ceff30ddab4e756e3a70ece45076eb17ff2f587a068dae657d2ad3a265a3f0d6

Previously what was happening is that in Rails during creation of the record with association assignment was used:

l['source_type'] = 'Animal'

Now it has been replaced with _write_attribute:

l._write_attribute('source_type', 'Animal')

The result l.source_type of the former is "Animal" and the result of the latter is nil.

@wendy-clio so I successfully tracked down the change that causes the tests to fail now.

However I'm still unsure on what we can do on the gem's side and what would we need to update in order to fix the gem and make it compatible with Rails 7.1.

@wendy-clio is there any suggestions you might provide on the potential fix? I assume you know more about about how the gem integrates with Rails.

[wendy-clio]

Hello @wendy-clio !

I made some research on Rails 7.1 support with polymorphic_integer_type gem.

Here's what I've found.

There's one test that fails once Rails is set to 7.1 version.

Here's the test that fails:

Failures:

  1) PolymorphicIntegerType When a link is created through an association and the link is accessed through the associations should have the proper source
     Failure/Error: expect(source.source_links[0].source).to eql source
     
       expected: #<Animal id: 1, name: "Alexi", type: nil, kind: "Cat", owner_id: nil>
            got: nil
     
       (compared using eql?)
     # ./spec/polymorphic_integer_type_spec.rb:182:in `block (4 levels) in <top (required)>'
     # ./spec/spec_helper.rb:42:in `block (3 levels) in <top (required)>'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/transaction.rb:535:in `block in within_new_transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activesupport-7.1.3.4/lib/active_support/concurrency/null_lock.rb:9:in `synchronize'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/transaction.rb:532:in `within_new_transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/connection_adapters/abstract/database_statements.rb:344:in `transaction'
     # /home/senya/.rvm/gems/ruby-3.2.2/gems/activerecord-7.1.3.4/lib/active_record/transactions.rb:212:in `transaction'
     # ./spec/spec_helper.rb:41:in `block (2 levels) in <top (required)>'

Finished in 4.21 seconds (files took 0.60888 seconds to load)
1 example, 1 failure

I've tracked down the change in Rails that is causing the failure.

The change is this line: rails/rails@7b6720d#diff-ceff30ddab4e756e3a70ece45076eb17ff2f587a068dae657d2ad3a265a3f0d6

Previously what was happening is that in Rails during creation of the record with association assignment was used:

l['source_type'] = 'Animal'

Now it has been replaced with _write_attribute:

l._write_attribute('source_type', 'Animal')

The result l.source_type of the former is "Animal" and the result of the latter is nil.

@wendy-clio so I successfully tracked down the change that causes the tests to fail now.

However I'm still unsure on what we can do on the gem's side and what would we need to update in order to fix the gem and make it compatible with Rails 7.1.

@wendy-clio is there any suggestions you might provide on the potential fix? I assume you know more about about how the gem integrates with Rails.

Sorry for the delay. I think the main problem is somehow rails changes its behaviour of not reloading the activeRecord after .write_attribute method which write the value directly into db.
To keep the same behaviour, we can simply call a reload after the following line

polymorphic_integer_type/lib/polymorphic_integer_type/polymorphic_foreign_association_extension.rb

Line 7 in c9ad377

record._write_attribute(reflection.foreign_integer_type, reflection.integer_type)

or to keep the same pattern with rails update, just add a reload on the failing test which is the typical behaviour of needing to reload the owner object after the association has create directly against db.

[wendy-clio]

Upgraded on version 3.3.0