If grouping at submission is the concern here, then it would be more than easy to do - the idea here (maybe I did not communicate it properly) was to use the ExecDB generated UUID as the identifier, the same way we do in the whole stack. Since the Groups can be created "on the fly" (meaning, that if you submit a result, with a group-uuid that is not yet in the database, it is created for you), we would not need to worry about it at all. If we wanted to be a bit more descriptive, we could create the Group, and set the Name/Description during trigger time (probably as a part of creating the execdb job).
This would, of course, lead to having the 'exec_url' set in the Group's 'ref_url' and thus having the back-reference "by convention", as we have it now, with Job. I don't think that either of the options (exec_url in Result, or using group "by convention") is necessarily better than the other, it's mostly about what semantics we want to have.
Having the link to execdb in a group (as we do it right now) seems as a fine approach to me.
The last question to ask is, whether the "execution grouping" is even something usefull - what do we (would we) use the information that "these X results come from the same execution"? Is it even something we care about?
Currently it is the only way to display dist.rpmgrill* (including subchecks) results for a NVR. Also, it is useful when e.g. looking at what a single upgradepath run reported - I can quickly and easily see everything that was reported during that single task execution.
I don't think that having a "This was executed together" group that big of a deal, the problem I see (and I'm not sure it's really a problem) is that if we have Result in multiple Groups, then linking from ResultsDB to ExecDB can not be done programatically (which group is the "this was executed together", and which are "something else) without relying to convention (like beginning the name of the "exec" group with "Taskotron Execution").
Using conventions is fine in my POV. Either name prefix, or arbitrary tag on the group, etc.
Tim wrote:
This would mean that we can find the job that every result came from without having to worry about grouping them at submission time. I can think of use cases where there either be no need for a job UUID/URI or one would not exist, hence the suggestion that the column could be empty.
What are the use cases? I can think of one - yesterday Adam mentioned he would like to save manual test results into resultsdb (using a frontend). That would have no ExecDB entry (no UUID). Is that a problem in the current design? This also means we would probably not create a group for this result - is that also OK?