-
Notifications
You must be signed in to change notification settings - Fork 897
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
[WIP] fix association between EMS and ConfigurationSystem #16798
Closed
Closed
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 believe it was on purpose, that the relations were only on automation_manager, we do the same for cloud_manager, etc.
I think the base of you failing specs is that the mock data are not valid. Each model has to have a correctly filled STI type, like it always has when it comes from a refresh.
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.
Yes, true that the failing specs can be fixed by using the corresponding factory for
automation_manager
.But what I have question about is that, why on one side we define the relationship in base class
ExtManagementSystem
and the other side in the subclassAutomationManager
? Is this a proper practice in rails?The other point is that: If the concept of a
EMS
has manyConfiguredSystem
is valid at base class level, we should be able to test it.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.
Hm so I think the idea was to have manager specific relations only under the specific manager, e.g. cloud manager https://github.com/Ladas/manageiq/blob/be7d05ca1089fa0c06802c2bfa666d5b9e10f455/app/models/manageiq/providers/cloud_manager.rb#L17
Then the relations would not work, unless the proper STI types are set, so all specs have to set them right.
But I've seen that e.g. if relation is shared by more types of managers, it goes to ext_management_system.rb. Which is your case, so this should be acceptable.
Or e.g. for complex virtual attributes, it easier to have the relation on base class, otherwise it might give unexpected results.