Endpoint to upload HF all.json about horreum

[rvansa]

So, I think each upload of run that is not parsed into repo-native structure should consist of (test, schema, data-matching-the-schema). For each allowed schema the test will define bunch of jsonpath-ish transformations that will select these generic arguments + view. Ofc the schema will be validated here as well.

[willr3]

@rvansa I don't think I understand what you mean by

consist of (test, schema, data-matching-the-schema)

Right now RunService.addRunFromData is exposed as POST /run/data and accepts 3 query params (start, stop, test) in addition to the json post body. The query params can be either jsonpath (starting with $.) or string literals that are parsed into the expected format (e.g. parsing an ISO data string or treating test as the ID or name of an existing test)
There is also RunService.addHyperfoilRun exposed as POST /run/hyperfoil which is the same as using /run/data with start=$.info.startTime stop=$.info.terminateTime and test=$.info.benchmark
In both cases, a new test will be created if the test query parameter does not find an existing test definition.
Do you think we should create a new test definitions based on $.info.benchmark by default?
Do you think the uploaded json to /run/hyperfoil should first get validated against the most recent hyperfoil json-schema?

[rvansa]

Right now RunService.addRunFromData is exposed as POST /run/data and accepts 3 query params (start, stop, test) in addition to the json post body. The query params can be either jsonpath (starting with $.) or string literals that are parsed into the expected format (e.g. parsing an ISO data string or treating test as the ID or name of an existing test)
There is also RunService.addHyperfoilRun exposed as POST /run/hyperfoil which is the same as using /run/data with start=$.info.startTime stop=$.info.terminateTime and test=$.info.benchmark
In both cases, a new test will be created if the test query parameter does not find an existing test definition.

Okay, I have assumed that tests should be defined first and the upload should fail if it's not, as a precaution to mistyping the test name. I grok that not requiring to create it is convenient, though. This workflow just says that the json -> view transformation can come later. That also means that schema is optional in the sense of using some __any schema if there is no query param nor $schema key in the input.

I am not very fond of the addHyperfoilRun endpoint; Ideally I would keep the transformation as data rather than hardcoding it. If a run comes declaring schema belonging to Hyperfoil, it decide based on that.

Do you think we should create a new test definitions based on $.info.benchmark by default?

You've convinced me; yes. In my eyes that makes schemas the first-level citizen, storing any transformation for schema only, not for (test, schema) tuple.

Do you think the uploaded json to /run/hyperfoil should first get validated against the most recent hyperfoil json-schema?

Note that the Hyperfoil schema is for benchmark; all.json schema is yet to come. If a benchmark declares schema that's unknown to repo, it can't validate it but I don't think it has to refuse the upload. There should be exclamation marks in the UI, though.

[rvansa]

I've just noticed that view is defined in Test table; I though that view is a cached excerpt from full Run's data - does it have a different purpose than I thought?

[rvansa]

Oh gosh there's javascript in the DB! I found the tab...

[rvansa]

I think this is done. Schema entity now defines the paths to fetch those parameters from the JSON.