)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1921,"name":"Andrea Frittoli","email":"andrea.frittoli@gmail.com","username":"andrea-frittoli"},"change_message_id":"4adad3f731ce76abc6663d96693762f21ea3cd25","unresolved":false,"context_lines":[{"line_number":10,"context_line":"runs table. These columns are to represent common run metadata fields"},{"line_number":11,"context_line":"that are often always set for runs. Using these instead of as a key"},{"line_number":12,"context_line":"value pair in run_metadata should have a performance improvement"},{"line_number":13,"context_line":"since they avoid doing a join. However, there is no obligation for"},{"line_number":14,"context_line":"users to use them and run_metadata will continue to be supported and"},{"line_number":15,"context_line":"work as always. These fields are not part of subunit and kept generic"},{"line_number":16,"context_line":"on purpose just to give a place in the runs table to keep some basic"},{"line_number":17,"context_line":"metadata."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"ba2be162_37f554ec","line":15,"range":{"start_line":13,"start_character":31,"end_line":15,"end_character":14},"updated":"2017-03-06 11:54:57.000000000","message":"I agree there should be no obligation for using this metadata, but I think we should at least put a constraint that for those specific metadata items, if used, they should be in the run table rather than run_metadata.\nOtherwise clients will have no way of knowing where to get that metadata from, unless we introduce a new config option for graph and API to tell where to get those bits of metadata from.","commit_id":"602873d3f0570a43c4bc442d0aa702a5d3d9b788"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"843ad382c0b93555654535995bd94fd61974a19f","unresolved":false,"context_lines":[{"line_number":10,"context_line":"runs table. These columns are to represent common run metadata fields"},{"line_number":11,"context_line":"that are often always set for runs. Using these instead of as a key"},{"line_number":12,"context_line":"value pair in run_metadata should have a performance improvement"},{"line_number":13,"context_line":"since they avoid doing a join. However, there is no obligation for"},{"line_number":14,"context_line":"users to use them and run_metadata will continue to be supported and"},{"line_number":15,"context_line":"work as always. These fields are not part of subunit and kept generic"},{"line_number":16,"context_line":"on purpose just to give a place in the runs table to keep some basic"},{"line_number":17,"context_line":"metadata."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":4,"id":"ba2be162_09ad909a","line":15,"range":{"start_line":13,"start_character":31,"end_line":15,"end_character":14},"in_reply_to":"ba2be162_37f554ec","updated":"2017-03-06 15:19:57.000000000","message":"For the DB API it\u0027s literally just a matter of adding the corresponding DB API functions for the new columns where it makes sense. From what I can tell from a quick grepping it\u0027s just:\n\ndef get_recent_runs_by_key_value_metadata()\ndef get_run_times_grouped_by_run_metadata_key()\ndef get_run_times_time_series_grouped_by_run_metadata_key()\ndef get_run_failure_rate_by_key_value_metadata()\ndef get_recent_failed_runs_by_run_metadata()\ndef get_runs_counts_by_run_metadata()\ndef get_runs_by_status_grouped_by_run_metadata()\ndef get_recent_successful_runs_by_run_metadata()\n\nIt\u0027s not clear if we\u0027d need 3 additional functions for each of those or not. (but likely so)\n\nFor the graph commands it\u0027s actually not that bad. We only have 2 commands that use metadata today run_time_meta and run_failure_rate. Both just take a metadata key in as a parameter for their graph generation. My idea to fix those was going to be to just add a flag for each of the 3 new columns. So you either specify a metadata key or set --run_name, --run_type, or --project on the command to use any of those.","commit_id":"602873d3f0570a43c4bc442d0aa702a5d3d9b788"}],"releasenotes/notes/Add-migration-for-run-meta-columns-5974c07332cd6cd9.yaml":[{"author":{"_account_id":1921,"name":"Andrea Frittoli","email":"andrea.frittoli@gmail.com","username":"andrea-frittoli"},"change_message_id":"4adad3f731ce76abc6663d96693762f21ea3cd25","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"ba2be162_d7df980a","updated":"2017-03-06 11:54:57.000000000","message":"I think it may be worth noting that while we are adding these columns, they are actually not used nor supported by the python API.","commit_id":"602873d3f0570a43c4bc442d0aa702a5d3d9b788"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"843ad382c0b93555654535995bd94fd61974a19f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"ba2be162_a90724c8","in_reply_to":"ba2be162_d7df980a","updated":"2017-03-06 15:19:57.000000000","message":"Well it is supported by the python api in that it will be returned with methods that return a Run sqlalchemy object. But, the explicit methods that will deal with filtering based on the data are going to happen in a follow up patch.","commit_id":"602873d3f0570a43c4bc442d0aa702a5d3d9b788"}]}