STI in Katello

I noticed that 4 katello tables have a 'type' for field for STI.

katello_content_view_filters
class ContentViewErratumFilter < ContentViewFilter
class ContentViewPackageFilter < ContentViewFilter
class ContentViewPackageGroupFilter < ContentViewFilter

katello_products
class MarketingProduct < Product

katello_task_statuses
class PulpTaskStatus < TaskStatus

katello_systems
type db field not used

It doesn't appear that we need the 'type' field in katello_systems for STI, so I am renaming it to 'system_type'. https://github.com/Katello/katello/pull/4421

However, I don't understand the apipie docs in katello/app/controllers/katello/api/v2/systems_controller.rb

def_param_group :system do
param :type, String, :desc => N_("Type of the content host, it should always be 'content host'"), :required => true, :action_aware => true

but in the POST and PUT actions, it says
param :type, String, :desc => N_("Type of the content host, it should always be 'system'"), :required => true, :action_aware => true

However, in the db, type is 'Katello::System'.
I don't think we want to tell the API uses to pass 'content host' or 'system' as the type. If so, it breaks on my dev environment.

On the STI topic, I think it would be cleaner to have katello models inherit from ActiveRecord::Base rather than Katello::Model which is only used to turn on/off strong_parameters. Are there any objections to re-factoring this as a mixin or extension of Active::Model rather than using inheritance.

module Katello
class Model < ActiveRecord::Base
self.abstract_class = true

# remove once foreman has strong_parameters or Rails 4
include Katello::ForbiddenAttributesProtection

def destroy!
  unless destroy
    fail self.errors.full_messages.join(&#39;; &#39;)
  end
end

end
end

Regards,

Joseph

> I noticed that 4 katello tables have a 'type' for field for STI.
>
> katello_content_view_filters
> class ContentViewErratumFilter < ContentViewFilter
> class ContentViewPackageFilter < ContentViewFilter
> class ContentViewPackageGroupFilter < ContentViewFilter
>
> katello_products
> class MarketingProduct < Product
>
> katello_task_statuses
> class PulpTaskStatus < TaskStatus
>
> katello_systems
> type db field not used
>
> It doesn't appear that we need the 'type' field in katello_systems for STI, so I am renaming it to 'system_type'. https://github.com/Katello/katello/pull/4421
There is a Hypervisor class which relies on the sti relationship. I
think the method that has been defined of 'type' is a mistake and should
be renamed to something else.

> However, I don't understand the apipie docs in katello/app/controllers/katello/api/v2/systems_controller.rb
>
> def_param_group :system do
> param :type, String, :desc => N_("Type of the content host, it should always be 'content host'"), :required => true, :action_aware => true
>
> but in the POST and PUT actions, it says
> param :type, String, :desc => N_("Type of the content host, it should always be 'system'"), :required => true, :action_aware => true
>
> However, in the db, type is 'Katello::System'.
> I don't think we want to tell the API uses to pass 'content host' or 'system' as the type. If so, it breaks on my dev environment.

I think this is where the confusion is. There is an STI type and this
method 'type' which returns a human readable string. I'm honestly
surprised this hasn't caused any issues before now.

>
>
> On the STI topic, I think it would be cleaner to have katello models inherit from ActiveRecord::Base rather than Katello::Model which is only used to turn on/off strong_parameters. Are there any objections to re-factoring this as a mixin or extension of Active::Model rather than using inheritance.

Does this actually cause a problem? Or just a best practice sort of thing?

-Justin

··· On 07/15/2014 05:12 AM, Joseph Magen wrote: > > module Katello > class Model < ActiveRecord::Base > self.abstract_class = true > > # remove once foreman has strong_parameters or Rails 4 > include Katello::ForbiddenAttributesProtection > > def destroy! > unless destroy > fail self.errors.full_messages.join('; ') > end > end > end > end > > > Regards, > > Joseph >

> I noticed that 4 katello tables have a 'type' for field for STI.
>
> katello_content_view_filters
> class ContentViewErratumFilter < ContentViewFilter
> class ContentViewPackageFilter < ContentViewFilter
> class ContentViewPackageGroupFilter < ContentViewFilter
>
> katello_products
> class MarketingProduct < Product
>
> katello_task_statuses
> class PulpTaskStatus < TaskStatus
>
> katello_systems
> type db field not used
>
> It doesn't appear that we need the 'type' field in katello_systems for
> STI, so I am renaming it to 'system_type'.
> fixes #6596 - change 'type' method to 'system_type' in Katello::System by isratrade · Pull Request #4421 · Katello/katello · GitHub
>
> However, I don't understand the apipie docs in
> katello/app/controllers/katello/api/v2/systems_controller.rb
>
> def_param_group :system do
> param :type, String, :desc => N_("Type of the content host, it should
> always be 'content host'"), :required => true, :action_aware => true
>

This type is not something that should be really exposed to the user. This
may help explain better -
https://github.com/Katello/katello/pull/4369#issuecomment-47667829

>
> but in the POST and PUT actions, it says
> param :type, String, :desc => N_("Type of the content host, it should
> always be 'system'"), :required => true, :action_aware => true
>
> However, in the db, type is 'Katello::System'.
> I don't think we want to tell the API uses to pass 'content host' or
> 'system' as the type. If so, it breaks on my dev environment.
>
>
> On the STI topic, I think it would be cleaner to have katello models
> inherit from ActiveRecord::Base rather than Katello::Model which is only
> used to turn on/off strong_parameters. Are there any objections to
> re-factoring this as a mixin or extension of Active::Model rather than
> using inheritance.
>
> module Katello
> class Model < ActiveRecord::Base
> self.abstract_class = true
>
> # remove once foreman has strong_parameters or Rails 4
> include Katello::ForbiddenAttributesProtection
>
> def destroy!
> unless destroy
> fail self.errors.full_messages.join('; ')
> end
> end
> end
> end
>

We did this originally to make it easier to include/remove things that
every model uses. For example, when strong parameters is included by
default then we can simply remove this from one place instead of every
model in order to account for it. I believe David Davis made this change if
you'd like more insight as to why.

··· On Tue, Jul 15, 2014 at 5:12 AM, Joseph Magen wrote:

Regards,

Joseph


You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.