-
Notifications
You must be signed in to change notification settings - Fork 898
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
add binding to determine which method to use in relationship mixin #20274
add binding to determine which method to use in relationship mixin #20274
Conversation
20d1e2e
to
d3298cd
Compare
d3298cd
to
0df8369
Compare
3744bce
to
ccc2cb4
Compare
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 looks great.
- sorry, but I like the guard clause, it has less changes
- yea, since the arguments are different for ancestry and this, we probably need to pass args
- pass in ancestry parameters and not tge params that we require. I do wonder if we can drop the
*_args
parameters. - I'm a little worried about the differences in
parent=
- moving toupdate(:parent => )
or setting the parent when the vm is created may be our best bet - think batch refresh (openshift and at least 1 other) may feel this change
ccc2cb4
to
53f689a
Compare
596af70
to
55e779a
Compare
55e779a
to
2f6afdb
Compare
@kbrock you were right about the args getting stomped, it's somewhere around https://github.com/matthewrudy/memoist/blob/v0.15.0/lib/memoist.rb#L213 which is the reason why i have that gook |
c55a649
to
d5daeea
Compare
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 these changes - this looks great.
Anything outstanding or can we un-WIP it?
parent.with_relationship_type(relationship_type) { parent.add_child(self) } | ||
end | ||
|
||
def add_children(*child_objs) | ||
return child_objs.each { |child| child.with_relationship_type(relationship_type) { child.update!(:parent => self) } } if use_ancestry? | ||
|
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 regardless, either the child will have the wrong parent or the parent will have the wrong children. This is the nature of active record in general. I'm ok with this line.
ancestor_ids.include?([obj.class.base_class.name, obj.id]) | ||
end | ||
|
||
def is_ancestor_of?(obj) | ||
return obj.with_relationship_type(relationship_type) { obj.descendant_of?(self) } if use_ancestry? |
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.
looking up descendant ids is a database call but looking up ancestors is not.
so calling is_descendant_of requires fewer queries.
marking as work in progress because i'm concerned about the behavior of the class variables:
see #20664 (comment) for the details |
2be70a8
to
de934a3
Compare
un-work in progressing because the |
de934a3
to
d56ac01
Compare
@kbrock could I please get one more review here? 🤞 |
d56ac01
to
d92e48c
Compare
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 like to move ahead with this one. we just branched off K and something risky like this needs to be done at the beginning of a release cycle - if we are lucky, then we will be able to remove the need for this by changing all the classes
@@ -26,6 +27,7 @@ module RelationshipMixin | |||
extend Memoist | |||
|
|||
cattr_accessor :default_relationship_type | |||
class_attribute :skip_relationships, :default => [] |
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 looks great - although, not sure if we want this to carry across all the classes. Will we tell all classes to skip ancestry that are in the chain? If yes, then this is great.
based on the value of default_relationship_type we need to either set an ancestry parent or a relationship parent as vms use both both parent= live on the ancestors that are proxies to each of the modules so you can call methods on any such ancestor with some black magic wherein you can unbind a method and bind it to some other object
d92e48c
to
6fefedb
Compare
Checked commit d-m-u@6fefedb with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint spec/models/mixins/relationship_mixin_spec.rb
|
we're trying to remove genealogy. since the relationship adding logic lives in the rel mixin, we need a way of differentiating that logic from actual ancestry logic so classes can use both.
based on the value of
skip_relationships
we need to either set an ancestry parent or a relationship parentboth
parent=
live on the ancestors that are proxies to each of the modules so you can call methods on any such ancestor with ruby magic wherein you can unbind a method and bind it to some other object.@miq-bot assign @kbrock