Nice! This is a good start along with fedora-infra/statscache_plugins#1

@ralphbean yes, I will update the mimetype. 👍 for the default body message too.

@ralphbean the frequency param needed to load plugins, get plugin, etc. is getting a bit messy. And, dealing with frequency in the view layer does not make sense. The frequency then should reflect in generating unique plugin ids too. And, frequencies make sense for the producer only, and plugin Id makes sense for all other cases.

Currently, a plugin links to different models based on frequency. This is like overloading the plugin class. I think that there should be one-one-mapping between database tables and a plugin. And load plugins and get plugins should be frequency agnostic. The producers, if they want can filter plugins which match a frequency.

Please share your thoughts on it.

That makes sense -- 👍 to it.

Then the plugin classes can subsume the logic in make_model(frequency).

@ralphbean I am having a query regarding the above discussed refactor. Even if we have the frequency param moved to Plugin definition, still we have a dependency on the Producer instances with matching frequency to make the plugin work. Why not we make the plugins standalone? Why don't we have a single producer/dispatcher and plugins implements their own logic of bucketing data and saving it to the database?

Why don't we have a single producer/dispatcher and plugins implements their
own logic of bucketing data and saving it to the database?

That will work too and might make the whole thing more simple. Give it a try
and see how it shakes out.

Did you see I pushed some commits to a feature branch on the main repos?

https://github.com/fedora-infra/statscache/tree/categorized_log_model
https://github.com/fedora-infra/statscache_plugins/tree/fedore_rel_eng_board

@ralphbean Thanks a lot! I pulled your changes :) They look perfect. 👍