On Mon, 15 Aug 2016 22:48:38 +0200
Josef Skladanka <jskladan(a)redhat.com> wrote:
Hey gang,
I spent most of today working on the new API docs for ResultsDB,
making use of the even better Apiary.io tool.
Before I put even more hours into it, please let me know, whether you
think it's fine at all - I'm yet to find a better tool for describing
APIs, so I'm definitely biased, but since it's the Documentation, it
needs to also be useful.
http://docs.resultsdb20.apiary.io/
I am also trying to put more work towards documenting the attributes
and the "usual" queries, so please try and think about this aspect of
the docs too.
After the conversation about resultsdb yesterday, I have a proposal for
a change to ResultsDB and clarification about how we'd be using it in
Taskotron to answer some of the questions I asked earlier.
1. Add a null-able column to result to indicate the job it came from.
This could be a URI or just UUID so long as the final URI could be
computed from whatever is stored in this new column.
2. Change "group" to "tag" and plan on it being used for the grouping
of results by/for humans. This isn't something that we'd be making
use of right away but it seems like a logical feature to add given
where things are going.
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.
How does this sound? Any suggestions, concerns or comments?
Tim