Skip to content
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 5.2 support, drop Rails 4.2 support. #887

Merged
merged 9 commits into from
Jun 6, 2018
Merged

Conversation

Fodoj
Copy link
Contributor

@Fodoj Fodoj commented Feb 24, 2018

Based on #872 with extra changes on top

I've also dropped Rails 4.2 support, as it requires lots of hacking around in the code - dirty implementation changed a lot since then.

This PR rolls back cc7a2c0 as it breaks all PostgreSQL builds (including master branch).

Upd 26.05.18: ready to merge!

@Fodoj Fodoj mentioned this pull request Feb 24, 2018
@Fodoj Fodoj changed the title Rails 5.2 compatibility WIP: Rails 5.2 compatibility Feb 24, 2018
@Fodoj Fodoj changed the title WIP: Rails 5.2 compatibility Rails 5.2 compatibility Feb 24, 2018
Copy link

@thromera thromera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking care of it :).

context 'when language_list changed by association' do
let(:tag) { ActsAsTaggableOn::Tag.new(name: 'one') }

before(:each) do
Copy link

@thromera thromera Feb 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would refactor this to

it 'flags language_list as changed' do
  expect(@taggable.changes).to be_empty
  @taggable.languages << tag
  expect(@taggable.language_list_changed?).to be_truthy
end

Unless there is a specific guideline around it, I usually tend to not over-use the before-each, harder to read. Since here you have only one test in your context, I would drop it.

expect(@taggable.language_list_changed?).to be_truthy
end
end

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Un-needed new line

@@ -28,12 +28,16 @@ def initialize_acts_as_taggable_on_core
has_many context_taggings, -> { includes(:tag).order(taggings_order).where(context: tags_type) },
as: :taggable,
class_name: 'ActsAsTaggableOn::Tagging',
dependent: :destroy
dependent: :destroy,
after_add: :dirty_tag_list,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we name the callback dirtify_tag_list instead? Same for the after_remove callback.

@Fodoj Fodoj force-pushed the rails-5.2 branch 2 times, most recently from 37d5f77 to 2bcf065 Compare March 3, 2018 09:02
@Fodoj Fodoj changed the title Rails 5.2 compatibility Rails 5.2 support, drop Rails 4.2 support. Mar 3, 2018
@Fodoj
Copy link
Contributor Author

Fodoj commented Mar 3, 2018

@Erowlin I've incorporated your valuable feedback :) I've also updated PR description, dropped Rails 4.2 support and fixed tests. They still somehow failed in same combinations, I will try re-triggering to see what happens.

@criticerz
Copy link

@Fodoj Thanks! Really saved our butts with this PR.

@lunaru
Copy link
Contributor

lunaru commented Mar 9, 2018

I noticed that there's also another PR for a similar fix: #862

Any relationship between these two branches?

Anyway, I'd love to see this get merged!

@Fodoj
Copy link
Contributor Author

Fodoj commented Mar 9, 2018

@lunaru yes, I used code from 862 in this PR, forgot to mention it

@PhilCoggins
Copy link

@Fodoj Shouldn't the old version also be tracked?

Example:

i.label_list
=> ["foo", "bar", "low priority"]
i.label_list = "foo"
=> "foo"
i.changes
=> {"label_list"=>[nil, ["foo"]]}

I would expect the old array to display as the first value in i.changes array.

@travisofthenorth
Copy link

🎉 very happy to see this close to the finish line

@cantino
Copy link

cantino commented Apr 27, 2018

Is this fully blocked on Rspec 3.8?

@spaghetticode
Copy link

👍 I'm having issues with rails 5.2 and the current gem release so I hope this gets merged soon

@Fodoj
Copy link
Contributor Author

Fodoj commented May 16, 2018

@cantino yep, this is the last dep, once there is a new rspec release, I will update it here and PR is good to merge

@PhilCoggins
Copy link

@Fodoj Any thoughts on my comment above? I think this is at least worth addressing before merging. The changeset always being nil -> [foo, bar] isn't correct.

The reason this isn't working is because the model's attribute is not being initialized with the current list.

@cireficc
Copy link

You, my man, are a fricking life saver! I'm very excited to see this merged!

@Fodoj
Copy link
Contributor Author

Fodoj commented May 18, 2018

@PhilCoggins which Rails version do you use? There are tests for this behavior and from what I can see tracking works fine, for example:

taggable = TaggableModel.create(tag_list: 'awesome, epic')
#=> #<TaggableModel:0x000056219f1b3200 id: 2, name: nil, type: nil>
taggable.tag_list = 'foo'
#=> "foo"
taggable changes
#=> {"tag_list"=>[["awesome", "epic"], ["foo"]]}

See also spec/acts_as_taggable_on/taggable/dirty_spec.rb

Basically, the gem already had pretty good test coverage around dirty changes, so I relied on them to tell me if behaviour is the same.

@PhilCoggins
Copy link

@Fodoj Yes, if the model is initialized with the label list, then it works properly. But what about when I instantiate an already existing record?

i = Issue.create(label_list: "foo, bar")
i.label_list = "baz"
i.changes
=> {"label_list"=>[["foo", "bar"], ["baz"]]} # Good
i = Issue.find(i.id)
i.label_list = "baz"
i.changes
=> {"label_list"=>[nil, ["baz"]]} # Bad

Using Rails 5.1.4, FWIW.

@Fodoj
Copy link
Contributor Author

Fodoj commented May 18, 2018

Got it now, let me fix it :)

@Fodoj
Copy link
Contributor Author

Fodoj commented May 18, 2018

@PhilCoggins should be fixed now, though let's wait for Travis to confirm. I've added a spec as a proof that it's fixed: 7b4911a.

@PhilCoggins
Copy link

@Fodoj I just tested on my end, works great! Thank you for addressing this 💯 .

@brchristian
Copy link

Hi @Fodoj, it looks to me like all of the Rspec commits since 3.7 are just edits to the README. Are you sure we can’t just use Rspec 3.7 instead of the master branch?

Then we wouldn’t have to wait to merge. :)

@Fodoj
Copy link
Contributor Author

Fodoj commented Jun 4, 2018

@seuros shot myself in a leg, but now it's fine, single beautiful commit with all the changes. Also added changes you've requested.

@seuros
Copy link
Collaborator

seuros commented Jun 4, 2018

@Fodoj Thank you. Do you know why Postgresql build started to fail after the rebase ?

@Fodoj
Copy link
Contributor Author

Fodoj commented Jun 5, 2018

@seuros it started to fail because master branch is failing https://github.com/mbleigh/acts-as-taggable-on/commits/master

@Fodoj
Copy link
Contributor Author

Fodoj commented Jun 5, 2018

@seuros I rolled back this commit, which started breaking builds 372741a.

Perhaps @rsl will have time to re-do it so that CI doesn't fail. I do not have time to dig deep into this escaping fix and really I think fixing is out of scope of this PR.

Copy link

@thromera thromera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thanks again for your work!

All minor comments, except one on the way we format the dirty tags, I think it's a breaking change and we should bump the gem to a major version just for that specific change.

I would like someone very familiar with the code base to review this as well.

Happy to discuss it if you need.

Thanks for your work!

Appraisals Outdated
@@ -1,11 +1,11 @@
appraise 'activerecord-5.2' do
gem 'activerecord', '5.2.0'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not using a version like ~> 5.2.0?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, why specifically 5.2 and not 5.0? In the Gemspec you specified 5.0, I suggest we stick with that version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get that. This is PR to add support for 5.2, why would I specify 5.0 in 5.2 appraisal?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we're dropping support for 4.2, it does not mean that we drop support for 5.0 I guess, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, that's why Appraisal file has definitions for 5.0, 5.1 and now for 5.2

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gem 'activerecord', '~> 5.2.0' will install the latest minor version of the 5.2 serie


source "https://rubygems.org"

gem "activerecord", "5.2.0"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment, why not sticking with 5.0?

end

taggable_mixin.class_eval <<-RUBY, __FILE__, __LINE__ + 1

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for this new line!

set_tag_list_on('#{tags_type}', new_tags)
end

def all_#{tags_type}_list
all_tags_list_on('#{tags_type}')
end

private
def dirtify_tag_list tagging
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add parenthesis for the parameters, it seems to be what's done in this project.

def dirtify_tag_list(tagging)
  ...
end

@@ -315,3 +316,4 @@ def find_or_create_tags_from_list_with_context(tag_list, _context)
end
end
end

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was fine actually, It's good to have a blank line at the end of files :). Sorry, I should have been more specific than a 👍
https://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-file

@@ -48,7 +48,7 @@ def tags_match_type

def escaped_tag(tag)
tag = tag.downcase unless ActsAsTaggableOn.strict_case_match
ActsAsTaggableOn::Utils.escape_like(tag)
tag.gsub(/[!%_]/) { |x| '!' + x }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one should be crazily spec'ed :).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just a rollback of cc7a2c0, nothing I wrote for this PR. That commit breaks builds in master branch.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can use ActsAsTaggableOn::Utils.escape_like(tag)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not to repeat myself, but this change is unrelated to the scope of this PR, as it barely rollbacks commit that broke the build here and in master branch

@@ -14,19 +14,27 @@
end

it 'should show changes of dirty object' do
expect(@taggable.changes).to eq({'tag_list' => ['awesome, epic', ['one']]})
expect(@taggable.changes).to eq({'tag_list' => [['awesome', 'epic'], ['one']]})
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️

This is a breaking change.

Either rollback your change or we have to communicate crazy about that. Our own internal code depends on the previous way it was formatted, and I bet a bunch of projects have the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Erowlin this PR is tagged for release 6.0.0, which is supposed to have breaking changes, no?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I guess we're fine!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a major breaking change that we should avoid.
People expect to have tags in the root of the array not inside another array.
Can we try to avoid this ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can not promise I will have any time to invest into it in next days/weeks. Even though new behaviour seems much more logical to me, because previously it was a change from string to array, and now it's change from array to array ( no akward change of data type).

@Fodoj
Copy link
Contributor Author

Fodoj commented Jun 5, 2018

I pushed more fixes. I actually assumed that after 3.5 months someone familiar with the code base already reviewed it, but seems like it's not the case?..

@thromera
Copy link

thromera commented Jun 5, 2018

I am not very familiar with the acts-as-taggable codebase unfortunately.

@Fodoj
Copy link
Contributor Author

Fodoj commented Jun 5, 2018

I assume as @seuros has permissions to merge to master, he is familiar. Let's wait for his final go and merge then.

Added new line back also.

Copy link

@ebihara99999 ebihara99999 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I met with the error and it's very helpful. I'd appreciate it if you could answer.


has_many context_tags, -> { order(taggings_order) },
class_name: 'ActsAsTaggableOn::Tag',
through: context_taggings,
source: :tag

attribute "#{tags_type.singularize}_list".to_sym, ActiveModel::Type::Value.new

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line makes taggable_obj.attribute_names changed. Specs failed in the following case, using json.extract! @item, *@item.attribute_names as response.

I saw you comment this PR will be released as the version 6.0.0 and allow breaking changes, but the impact of this change, if you don't expect, is very big.

What do you think about this case?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand the issue. Could you provide a failing spec?

Though I think if it's 6.0.0 release, then breaking changes are totally ok, just repo owner has to update readme before reasling this new version.

Copy link

@ebihara99999 ebihara99999 Jun 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Failing is request spec with the rspec-json_matcher gem. I copy and modify some from the real codes and output of running rspec:

# request spec
it { is_expected.to be_json_as [product: expected_product_response] }
# output
expected to match:

  {
    :product => {
      :id          => Integer < Numeric,
      :user_id     => Integer < Numeric,
      :product_id  => Integer < Numeric,
      :created_at  => String < Object,
      :updated_at  => String < Object,
    }
  }

actual:
  {
    :product => {
      "id"          => 2,
      "user_id"     => 11,
      "product_id"  => 216,
      "tag_list"    => [] # This is the difference
      "created_at"  => "2018-06-05T17:36:33+09:00",
      "updated_at"  => "2018-06-05T17:36:33+09:00"
    }
  }


reason: product "tag_list"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The case mentioned above is with the rspec-json_matcher gem, but if not using the rspec-json_matcher gem, the test suites testing api response would all fail because of the change.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion this change is harmful #1064

Appraisals Outdated
@@ -1,11 +1,11 @@
appraise 'activerecord-5.2' do
gem 'activerecord', '5.2.0'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gem 'activerecord', '~> 5.2.0' will install the latest minor version of the 5.2 serie

@@ -22,7 +22,7 @@ Gem::Specification.new do |gem|
gem.post_install_message = File.read('UPGRADING.md')
end

gem.add_runtime_dependency 'activerecord', ['>= 4.2.8']
gem.add_runtime_dependency 'activerecord', ['>= 5.0']
Copy link
Collaborator

@seuros seuros Jun 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gem.add_runtime_dependency 'activerecord', ['~> 5.0.0'] To avoid install in 6.*

@@ -174,7 +174,7 @@ module CalculationMethods
# See https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation/calculations.rb#L38
def count(column_name = :all, options = {})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the whole method can be removed now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried - some of tests fail, especially sqlite ones. Let's not risk it this time :)

@seuros seuros merged commit a1d0d30 into mbleigh:master Jun 6, 2018
@Onikoroshi
Copy link

Any idea when this will be available as a version? I'm still only able to get version 5.0.0 which doesn't seem to include this fix ...

@rsl
Copy link
Contributor

rsl commented Jun 15, 2018

@Fodoj i'm trying to work on "fixing" the PR that supposedly breaks the build. looking at the Travis report: https://travis-ci.org/mbleigh/acts-as-taggable-on/jobs/339031800#L657 it seems to be a gem/config issue that i cannot replicate nor see how my changes could possibly have affected.

Specified 'postgresql' for database adapter, but the gem is not loaded. Add gem 'pg' to your Gemfile (and ensure its version is at the minimum required by ActiveRecord).

i cannot get travis to retry my fork because the PR was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.