flux-accounting has lots of different tables that can be viewed with view-* and list-* commands, but each one has its own function that could probably be cleaned up with some common utility. Better yet, if the formatting options for all of these commands was centralized, it might make for easier changes in the future and/or customization of output by users.
This PR begins to centralize the formatting for flux-accounting by adding a new AccountingFormatter class to the Python bindings. The class takes a SQLite Cursor object that has the results of running a query on the flux-accounting database and offers two methods of formatting its data: data in an adjustable table or data in JSON format. Since this class just takes a Cursor object, this means it can support customization of what fields are formatted and returned (because the query itself can just be customized to not fetch every field).
I've also added a SQLite utility file to the Python bindings to also help centralize some of the basic SQL helpers I have throughout the bindings. I've started with just a simple validation function where, given a custom list of columns passed in, that list is then validated against what is actually defined in the flux-accounting database.
I've added some basic unit tests for the AccountingFormatter class and the utilization of the sql_util helper function.
Great suggestion @wihobbs! I'll open an issue on getting a flux-account(1) man page written. Probably should do that sooner rather than later since flux-accounting is getting used more and more. Setting MWP here
Problem
flux-accounting has lots of different tables that can be viewed with
view-*
andlist-*
commands, but each one has its own function that could probably be cleaned up with some common utility. Better yet, if the formatting options for all of these commands was centralized, it might make for easier changes in the future and/or customization of output by users.This PR begins to centralize the formatting for flux-accounting by adding a new
AccountingFormatter
class to the Python bindings. The class takes a SQLiteCursor
object that has the results of running a query on the flux-accounting database and offers two methods of formatting its data: data in an adjustable table or data in JSON format. Since this class just takes aCursor
object, this means it can support customization of what fields are formatted and returned (because the query itself can just be customized to not fetch every field).I've also added a SQLite utility file to the Python bindings to also help centralize some of the basic SQL helpers I have throughout the bindings. I've started with just a simple validation function where, given a custom list of columns passed in, that list is then validated against what is actually defined in the flux-accounting database.
I've added some basic unit tests for the
AccountingFormatter
class and the utilization of thesql_util
helper function.