-
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
Hook to support STI subclasses of Tag in save_tags #413
Conversation
Can you rebase against master and force push? |
Rebased. |
@@ -1,6 +1,7 @@ | |||
ActiveRecord::Schema.define :version => 0 do | |||
create_table :tags, :force => true do |t| | |||
t.string :name | |||
t.string :type |
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 column is only for the purpose of the STI tests, right? You're otherwise adding it yourself?
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.
Right, didn't want to make any changes to default generators and such since it isn't required for the basic, out-of-the-box plugin behavior, but I thought supporting extensibility and having at least light test coverage for it was worthwhile (I've done a lot more to support extensibility elsewhere, because I needed it, but it could use more tests before upstream submission).
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.
For completeness, I think, in the test, we should also set self.inheritance_column :type
so that we can explicitly set the STI column we'll be switching on. We should probably also check for the STI column in the code
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.
That sounds reasonable about inheritance_column
. What were you thinking for "check for the STI column in the code"? ActiveRecord probably lends some help with warnings/errors, but I can double-check, if any specific scenarios come to mind.
I'm really unsure if this is good functionality for the library as commented in the related issue. |
Well, that's certainly the maintainer's judgment call to make, whether a "plugin" has different extensibility goals than a "library" basically. If that is ultimately the decision, then I'll be maintaining a fork for the foreseeable future, because we needed the functionality in a real-world use case (more than one of them actually, but my example in #218 of followable tags is the most widely pertinent to offer as an example). Personally, I think it'd be kind of sad if a tagging library made a judgment that its users would never want to subclass its |
See if you can get it so there are no unused arguments or variables... I know the code is hard to work with |
@@ -72,13 +72,13 @@ def self.find_or_create_all_with_like_by_name(*list) | |||
|
|||
return [] if list.empty? | |||
|
|||
existing_tags = Tag.named_any(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.
Ah, this is definitely a good call. I missed that this was a subclassing issue unrelated to the STI issue.
Alright. Make sure all variables are used and we are gtg |
Merged in more commits to master, including your OCD branch, so this needs and update, ensure all variables are used, and its good to go |
@bf4, are we still going to merge this PR ? LGTM , it just need a rebase. |
I'll try to take a look at rebasing this again shortly. As noted in earlier discussion above though, regarding the insistence on not having an unused variable in the form of a parameter: the |
One use case I have is that a custom Tag class is "followable". Because `Core#save_tags` is a monstrous method, I was dirtily hacking around it on an override using `with_scope` around `super` -- this eliminates the need for such a trick.
Okay, rebased again. One thing to note though from the interim: #371 extracted the Though mine is long, I think |
Hook to support STI subclasses of Tag in save_tags
Hook to support STI subclasses of Tag in save_tags
One use case I have is that a custom Tag class is "followable" (see way back to #218). Because
Core#save_tags
is a monstrous method, I was hacking around it on an override usingwith_scope
aroundsuper
-- this eliminates the need for such a dirty trick.This is possibly incomplete support for
Tag
being robustly subclass-able, but I haven't run into any other issues yet with the features of acts-as-taggable-on that we're using.