Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • beat.core beat.core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 14
    • Issues 14
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • beatbeat
  • beat.corebeat.core
  • Merge requests
  • !65

Update the schemas to better reflect parameter type support in different objects

  • Review changes

  • Download
  • Email patches
  • Plain diff
Open Jaden DIEFENBAUGH requested to merge 74-parameter-schemas into master Mar 25, 2019
  • Overview 61
  • Commits 14
  • Pipelines 34
  • Changes 85

This fixes a couple schema issues regarding types definitions for parameters across different objects:

  • 1. basetype includes types only used by one object type - the complex numerical types are only valid in dataformats, and should be moved there
  • 2. parameter_value in the database schema is a duplicate of value defined in common.json
  • 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.
  • 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.
  • 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.
  • 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:
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     },
  • 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.
  • 8. Similarly as no.7, choice parameters don't distinguish between numerical types, and suffer the same issues.
  • 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 #74

Edited Apr 23, 2019 by Jaden DIEFENBAUGH
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: 74-parameter-schemas