Skip to content
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

Expose attribute_aliases as attributes #565

Merged
merged 1 commit into from
Feb 11, 2025

Conversation

kbrock
Copy link
Member

@kbrock kbrock commented Jan 30, 2025

Blocked:

TODO:

  • use all_attribute_names or what ever 23324 implements

Before

Attributes defined with alias_attribute were not exposed in automate models.
So we either had to edit the service models for each of these attributes, or we had to define virtual attributes for these attributes.

After

# NOTE: CloudObjectStoreObject.alias_attribute :name, :key
it "finds attributes aliases (without virtual attribute defined)" do
# if this shows true, find another model/attribute
expect(model.virtual_attribute?("name")).to eq(false)
Copy link
Member

@Fryguy Fryguy Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused what this is trying to show. For CloudObjectStoreObject, both "key" and "name" show up in attribute_names, so I feel like this test would pass without the code changes above. Same goes for Flavor with "cpus" and "cpu_cores"

irb(main):009> Flavor.attribute_names[-2..]
=> ["cpus", "cpu_cores"]
irb(main):010> Flavor.attribute_aliases.keys
=> ["cpus", "cpu_cores"]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for rails 7.1.

irb(main):002:0> Flavor.attribute_names.grep(/cpu/)
=> ["cpu_total_cores", "cpu_cores_per_socket", "cpu_sockets"]
irb(main):003:0> Flavor.attribute_aliases.keys.grep(/cpu/)
=> ["cpus", "cpu_cores"]

I think it's related to https://www.github.com/rails/rails/pull/52117 and the issue that caused it: https://www.github.com/rails/rails/issues/52111.

Basically, we can't do virtual_attribute on things that are aliased attributes. We're moving to just keeping alias_attribute and removing the virtual_attribute for aliased attributes. Therefore, we need to change automate to pull in aliased attributes since we can't rely on attributes/attribute_names to have them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the idea is to drop virtual_column or virtual_attribute on things that are aliased attributes, like this commit:

ManageIQ/manageiq@ae95f19

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We hack it into attribute_names for virtual columns. This doesn't work with rails 7.1 for aliased attributes because they changed how they work in rails 7.1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok thanks - I couldn't understand the context - I knew it was Rails 7.1, but it didn't make sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Fryguy @jrafanie Do we want to leverage ar_visible_attributes.rb here?

Maybe introduce hidden_and_non_hidden_attributes or all_attributes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like this? ManageIQ/manageiq#23324

jrafanie added a commit to ManageIQ/manageiq-cross_repo-tests that referenced this pull request Jan 30, 2025
@kbrock kbrock force-pushed the alias_attribute_access branch from b9aa202 to 6e92c8e Compare January 30, 2025 18:52
@@ -60,7 +60,7 @@ def self.ar_model_associations

def self.expose_class_attributes(subclass)
subclass.class_eval do
model.attribute_names.each do |attr|
(model.attribute_names | model.try(:attribute_aliases)&.keys).each do |attr|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find on this location. Does it make sense to have method that virtual attributes adds that provides this?

I see we have similar code here and ManageIQ/manageiq-api#1278. Perhaps, we could have something in core that extends AR to give us exposed_attribute_names so we can have one place to test that exposed_attribute_names includes virtual attributes, columns, aliased attributes, etc. Perhaps deprecated_attributes are in the same bucket.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrafanie Did you see my comment above?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above

@kbrock kbrock changed the title Expose attribute_aliases as attributes [WIP] Expose attribute_aliases as attributes Feb 4, 2025
@kbrock kbrock added the wip label Feb 4, 2025
@kbrock
Copy link
Member Author

kbrock commented Feb 4, 2025

WIP: introducing more generic method for the concept of attributes and attribute aliases. After that is done, will change this code to leverage that.

@kbrock
Copy link
Member Author

kbrock commented Feb 10, 2025

update:

  • using all_attribute_names

(hence - un-WIP)

@kbrock kbrock removed the wip label Feb 10, 2025
@kbrock kbrock changed the title [WIP] Expose attribute_aliases as attributes Expose attribute_aliases as attributes Feb 10, 2025
@kbrock kbrock force-pushed the alias_attribute_access branch from bec8203 to 18dff46 Compare February 10, 2025 16:13
@jrafanie jrafanie merged commit 69cb3c9 into ManageIQ:master Feb 11, 2025
3 checks passed
@jrafanie
Copy link
Member

Removed radjabov... we'll be doing rails 7.1 in spassky

@kbrock kbrock deleted the alias_attribute_access branch February 11, 2025 23:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants