beat.core merge requestshttps://gitlab.idiap.ch/beat/beat.core/-/merge_requests2018-09-18T17:27:27Zhttps://gitlab.idiap.ch/beat/beat.core/-/merge_requests/15WIP:Added support for run arguments2018-09-18T17:27:27ZSamuel GAISTWIP:Added support for run argumentsThis will allow to start a container with additional arguments
at run time.This will allow to start a container with additional arguments
at run time.Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/merge_requests/65Update the schemas to better reflect parameter type support in different objects2020-10-19T15:16:45ZJaden DIEFENBAUGHUpdate the schemas to better reflect parameter type support in different objectsThis fixes a couple schema issues regarding types definitions for parameters across different objects:
- [x] 1. `basetype` includes types only used by one object type - the `complex` numerical types are only valid in dataformats, and sh...This fixes a couple schema issues regarding types definitions for parameters across different objects:
- [x] 1. `basetype` includes types only used by one object type - the `complex` numerical types are only valid in dataformats, and should be moved there
- [x] 2. `parameter_value` in the database schema is a duplicate of `value` defined in common.json
- [x] 3. the `range` definition for algorithm range parameters, defined in `algorithm/common.json`, define ranges as an array of two elements, which may be a mix of strings, booleans, or numbers. They should only able to be numbers.
- [x] 4. the `choice` definition for algorithm choice parameters, defined in `algorithm/common.json`, let the items in the list of choices be strings, numbers, or booleans (mutually inclusive). Choice lists should only be strings if the parameter type is strings, or numbers if the parameter type is a number. They shouldn't, of course, ever be booleans.
- [x] 5. Range/choice parameters for algorithms should be restricted based on the parameter type. e.g., algorithms shouldn't be able to have a string-type parameter that's a range parameter, but currently that's actually accepted.
- [x] 6. Algorithm choice parameters have conflicting definitions for the keyword to declare the actual choices available. It defines a `range` key but requires a `choice` key. This was probably a typo but essentially breaks choice parameters. I'll fix the typo to define & require the `choice` keyword, not the `range` keyword. Here's the relevant snippet:
```json
107 "choice_parameter": {
108 "allOf": [
109 { "$ref": "#/definitions/parameter" },
110 {
111 "properties": {
112 "range": { "$ref": "#/definitions/choice" }
113 },
114 "required": [
115 "choice"
116 ]
117 }
118 ],
119 "additionalProperties": false
120 },
```
- [x] 7. Ranges for parameters have the same restrictions regardless if the type is an unsigned integer, signed integer, or floating-point. E.g. a `uint32` could have a range of `[-3.14159, -3.1]` and it would be considered valid, even though a valid value could never be assigned to the parameter.
- [x] 8. Similarly as no.7, choice parameters don't distinguish between numerical types, and suffer the same issues.
- [x] 9. Default values in parameters need the same treatment as above - distinguish between numerical types
I might find more and will add them above
Closes #74Samuel GAISTSamuel GAISThttps://gitlab.idiap.ch/beat/beat.core/-/merge_requests/69WIP: More work on schemas2019-06-14T08:29:41ZJaden DIEFENBAUGHWIP: More work on schemasCopied from #76:
Both !55 and !65 showed that there were places to improve the schema. This issue expands on those MRs' work by using the v6/v7 json schema features (where appropriate) and adding tests to complicated parts of the sche...Copied from #76:
Both !55 and !65 showed that there were places to improve the schema. This issue expands on those MRs' work by using the v6/v7 json schema features (where appropriate) and adding tests to complicated parts of the schema. Right now I know of a couple of things that need to be done:
- [x] Use the `const` schema keyword instead of the `enum` with only one choice. This issue is documented in the schema, e.g. in beat.core/beat/core/schema/algorithm/3.json:
```json
115- "type": {
116: "$comment": "Change enum to const when tools allow v6 json schema",
117- "type": "string",
118- "enum": ["loop_user"]
119- }
--
144- "type": {
145: "$comment": "Change enum to const when tools allow v6 json schema",
146- "type": "string",
147- "enum": ["loop"]
148- }
```
- [x] Specify JSON Schema Draft v.7 (versus Draft v.4)
- [ ] Use the `if`/`then`/`else` keywords from json schema v7 to represent more complex logic (e.g. the changes to algorithm parameters in !65)
- As found in !65, there are parts of the schema that aren't tested thoroughly. This is nebulous issue, however, so @flavio.tarsetti @samuel.gaist could you maybe specify what I should do here, so I don't go off the rails?
- [ ] Analyse, consolidate, and normalise ASCII character constraints in names across the schema, (see [the issue with the dash character](https://gitlab.idiap.ch/beat/beat.core/issues/76#note_41800))
- [x] Use the correct `integer` json schema keyword to denote integer type constraints
- [x] Require the `uniqueItems: true` constraint in objects where arbitrary user-defined keys are accepted (see comments for more info)
(As other issues are isolated, I'll add them to the list)
Closes #76