-
Notifications
You must be signed in to change notification settings - Fork 900
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
convert tag.category to a regular association #17418
Conversation
/cc @Fryguy you asked me to pull this out - sound good to you? |
@@ -6,7 +6,7 @@ def mapped_tag(category_name, tag_name) | |||
mapping = FactoryGirl.create(:tag_mapping_with_category, | |||
:category_name => category_name, | |||
:category_description => category_name) | |||
category = mapping.tag.category | |||
category = mapping.tag.classification |
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 does this have to change? The code is looking for the category, so it's surprising to ask for the classification
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.
Spoke with @cben about this (author of the test)
There is currently a bug in #category
name_path.split('/').first
means it will return a category
or classification
.
This test was relying upon a bug in #category
. Changing this line s/category/classification
still passes the tests.
In this test, there is category/tag (which really translates to classification/category)
Nice. However manageiq-providers-kubernetes & -openshift are failing with this, it seems there are tests there relying on same bug. Let me see if I can change them... |
A more detailed explanation, because the terminology in above discussion is IMHO overloaded:
Tag#category is supposed to get the "uncle", the category Classification from an entry Tag. The question is what it does / should do given a category Tag? |
Currently .category on a category Tag ("/managed/cat") happens to work same as .classification, but it's ill-defined and will stop working after ManageIQ/manageiq#17418. .parent category Classification "cat" <---------- entry Classification "ent" |^ ^ |^ .tag||.classification \_______________ .tag||.classification v| .category \ v| category Tag /managed/cat entry Tag /managed/cat/ent
Currently .category on a category Tag ("/managed/cat") happens to work same as .classification, but it's ill-defined and will stop working after ManageIQ/manageiq#17418. .parent category Classification "cat" <---------- entry Classification "ent" |^ ^ |^ .tag||.classification \_______________ .tag||.classification v| .category \ v| category Tag /managed/cat entry Tag /managed/cat/ent
|
Currently .category on a category Tag ("/managed/cat") happens to work same as .classification, but it's ill-defined and will stop working after ManageIQ/manageiq#17418. .parent category Classification "cat" <---------- entry Classification "ent" |^ ^ |^ .tag||.classification \_______________ .tag||.classification v| .category \ v| category Tag /managed/cat entry Tag /managed/cat/ent
For a regular tag (before and after): node.classification.parent == node.category node.classification != node.category There is an edge case for category tags that has changed: This edge case is used in tests. Note: category_tag = node.category.tag before: category_tag behaves differently from a category_tag category_tag.classification.parent != category_tag.category category_tag.classification == category_tag.category after: category_tag behaves the same as a category_tag category_tag.classification.parent == category_tag.category == nil category_tag.classification != category_tag.category
Thanks @cben for both your graph and the PRs for specs. Both help a lot Yes, when looking at the category node (dotted border) it gets a little confusing. node.classification.parent == node.category
node.classification != node.category So I've come to the conclusion that I've added a test to show the expected behavior. thnx to https://graphviz.glitch.me/ digraph G {
node [shape=Mrecord]
nil [label="nil"]
c_class [label="category classification 'cat'"]
e_class [label="entry classification 'ent'"]
c_tag [label="category tag '/managed/cat'" style="dashed"]
e_tag [label="entry tag '/managed/cat/ent'" style="bold"]
c_class -> e_tag [label="category" dir="back" constraint="false"]
nil -> c_class [label="parent" dir="back" constraint="false"]
c_class -> e_class [label="parent" dir="back" constraint="false"]
c_class -> c_tag [label="tag" constraint="false"]
c_class -> c_tag [label="classification" dir="back"]
e_class -> e_tag [label="tag"]
e_class -> e_tag [label="classification" dir="back"]
nil -> c_tag [label="category" dir="back" constraint="false"]
} |
Checked commit kbrock@fe708cd with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
assumptions make sense 👍. LGTM. |
dependencies all landed |
Use relationships instead of virtual relationships.
relationships are native to rails
pulled out of #17210
(probably retiring that PR, but want this change)