-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Conversation
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 | ||
|
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
37d5f77
to
2bcf065
Compare
@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. |
@Fodoj Thanks! Really saved our butts with this PR. |
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! |
@lunaru yes, I used code from 862 in this PR, forgot to mention it |
@Fodoj Shouldn't the old version also be tracked? Example:
I would expect the old array to display as the first value in |
🎉 very happy to see this close to the finish line |
Is this fully blocked on Rspec 3.8? |
👍 I'm having issues with rails 5.2 and the current gem release so I hope this gets merged soon |
@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 |
You, my man, are a fricking life saver! I'm very excited to see this merged! |
@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. |
@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?
Using Rails 5.1.4, FWIW. |
Got it now, let me fix it :) |
@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. |
@Fodoj I just tested on my end, works great! Thank you for addressing this 💯 . |
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 Then we wouldn’t have to wait to merge. :) |
@seuros shot myself in a leg, but now it's fine, single beautiful commit with all the changes. Also added changes you've requested. |
@Fodoj Thank you. Do you know why Postgresql build started to fail after the rebase ? |
…sses mbleigh#869" This reverts commit ac585c8.
…e; addresses mbleigh#869"" This reverts commit bc7ec0d.
@seuros it started to fail because master branch is failing https://github.com/mbleigh/acts-as-taggable-on/commits/master |
There was a problem hiding this 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' |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
gemfiles/activerecord_5.2.gemfile
Outdated
|
||
source "https://rubygems.org" | ||
|
||
gem "activerecord", "5.2.0" |
There was a problem hiding this comment.
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 | ||
|
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
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 } |
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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']]}) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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).
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?.. |
I am not very familiar with the acts-as-taggable codebase unfortunately. |
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. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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
acts-as-taggable-on.gemspec
Outdated
@@ -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'] |
There was a problem hiding this comment.
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 = {}) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
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 ... |
@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.
i cannot get travis to retry my fork because the PR was closed. |
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!