How to note a calculated default value in OAS3 - openapi

I'm updating my API spec (OAS 3.0.0), and am having trouble understanding how to properly model a "complex" default value.
In general, default values for parameters are scalar values (i.e. the field offset has a default value of 0). But in the API I'm spec'ing, the default value is actually calculated based on other provided parameters.
For example, what if we take the Pet model from the example documentation, and decide that all animals need to be tagged. If the user of the API wants to supply a tag, great. If not, it will be equal to the name.
One possibility:
Pet:
required:
- id
- name
properties:
id:
type: integer
format: int64
name:
type: string
tag:
type: string
default: '#/components/schemas/Pet/name'
This stores the path value as the default, but I'd like to have it explain that the default value will be calculated.
Bonus points if I can encode information from a parent schema.
Is the alternative to just describe the behavior in a description field?

OpenAPI Specification does not support dynamic/conditional defaults. You can only document the behavior verbally in the description.
That said, you can use specification extensions (x-...) to add custom information to your definitions, like so:
tag:
type: string
x-default: name
or
tag:
type: string
x-default:
propertyName: name
# or similar
and extend the tooling to support your custom extensions.

Related

OpenAPI 3.0 specifications - validating an array that is not required, but has minItems=1

optionalids:
type: array
items:
$ref: '#/components/schemas/Id'
minItems: 1
optionalIds is included inside another complex-type. and optionalIds is not a "required" property
Using openapi-codegen to generate code along with beanValidations.
The validation checks for the array optionalIds to at least contain one element. Since this is not a required property, not passing the optionalIds in the request should go through fine.
Is this understanding correct ?
What should be done to beanValidation templates so that this works

OpenAPI parameter with brackets and variable name

I am working on an API which allows searching with URLs like:
GET https://example.com/api/data?search[field1]=value1
GET https://example.com/api/data?search[field2]=value2
GET https://example.com/api/data?search[field1]=value1&search[field2]=value2
Basically, you can search for one or more field values by putting a field name in brackets. The problem is, the field names are defined by the user in their settings. The field name will be a string, but otherwise is not known ahead of time at a global level.
This answer is almost what I am looking to do, I just can't find a way to define the value inside the brackets to be "any string" rather than a list of known names.
The search parameter can be defined as a free-form object with the deepObject serialization style and minProperties: 1 to enforce the presence of at least one field in the search query.
Make sure you use OpenAPI 3.0 (openapi: 3.0.x) and not OpenAPI 2.0 (swagger: "2.0"); the latter does not support objects in query strings.
openapi: 3.0.2
...
paths:
/api/data:
get:
parameters:
- in: query
name: search
required: true
schema:
type: object
additionalProperties: true # Default value, may be omitted
minProperties: 1
# Optional example to use as a starting value for "try it out" in Swagger UI
example: >
{
"field1": "value1",
"field2": "value2"
}
style: deepObject
explode: true
responses:
200:
description: OK

OpenShift / Kubernetes explanation for each of the template fields

Sorry if this sounds like I'm lazy, but I've search around, around and around, but couldn't find it!
I'm looking for a reference that explains each of the fields that may exist in an OpenShift / Kubernetes template, e.g. what possible values there are.
The templates you get in OpenShift are OpenShift specific and not part of Kubernetes. If you mean the purpose of each of the possible fields you can specify for a parameter, you can run oc explain template. For example:
$ oc explain template.parameters
RESOURCE: parameters <[]Object>
DESCRIPTION:
parameters is an optional array of Parameters used during the Template to
Config transformation.
Parameter defines a name/value variable that is to be processed during the
Template to Config transformation.
FIELDS:
description <string>
Description of a parameter. Optional.
displayName <string>
Optional: The name that will show in UI instead of parameter 'Name'
from <string>
From is an input value for the generator. Optional.
generate <string>
generate specifies the generator to be used to generate random string from
an input value specified by From field. The result string is stored into
Value field. If empty, no generator is being used, leaving the result Value
untouched. Optional. The only supported generator is "expression", which
accepts a "from" value in the form of a simple regular expression
containing the range expression "[a-zA-Z0-9]", and the length expression
"a{length}". Examples: from | value -----------------------------
"test[0-9]{1}x" | "test7x" "[0-1]{8}" | "01001100" "0x[A-F0-9]{4}" |
"0xB3AF" "[a-zA-Z0-9]{8}" | "hW4yQU5i"
name <string> -required-
Name must be set and it can be referenced in Template Items using
${PARAMETER_NAME}. Required.
required <boolean>
Optional: Indicates the parameter must have a value. Defaults to false.
value <string>
Value holds the Parameter data. If specified, the generator will be
ignored. The value replaces all occurrences of the Parameter ${Name}
expression during the Template to Config transformation. Optional.
You can find more information in:
https://docs.openshift.org/latest/dev_guide/templates.html
If that isn't what you mean, you will need to be more specific as to what you mean. If you are talking about fields on any resource object (templates are specific type of resource object in OpenShift), you can use oc explain on any of them, pass the name of the resource type as argument, and then a dotted path as you traverse into fields. If using plain Kubernetes, you can use kubectl explain.

jasper server conditional mandatory on input controls

My question relates to jasper server 3.71
How can I conditionally make an input control mandatory. I wish to force the user to select from one query or another. In my case they must select from a list of Divisions OR from a list of Clients.
With thanks
Mark
This is not directly supported, however you could use a scenario where you define a third parameter which checks if either one or the other parameter is set. If the configuration is invalid you show an error message within the report instead of data.
Parameters:
parameter1, type: string, default value: none - deployed as input control
parameter2, type: string, default value: none - deployed as input control
verification, type: Boolean, default value: $P{parameter1} != null || $P{parameter2} != null - not deployed as input control
Band/Field Configurations:
As printWhen Expression of the detail band you add $P{verification} that means it will only be shown if the default expression for the verification parameter is true.
Define a text field in e.g. the title band giving an error message that either one of parameter1 and parameter2 need to be filled.

Mongoid and collections

I am trying to configure and use mongoid for the first time. I have set the mongoid.yml config file simply as:
host: localhost
database: table
and my code:
Mongoid.load!("/mongoid.yml")
class Data
include Mongoid::Document
field :study, type: String
field :nbc_id, type: String
field :short_title, type: String
field :source, type: String
field :start_date, type: Date
end
puts Data.study
I keep getting an error:
NoMethodError at / undefined method `study' for Data:Class
I think it is because I have not specified the collection name which is 'test'. However I can find no examples on how to do this. Do I specify it in the .yml file or in the code. What is the correct syntax. Can anyone point me in the right direction?
Tx.
According to the Mongoid documentation, "Mongoid by default stores documents in a collection that is the pluralized form of the class name. For the following Person class, the collection the document would get stored in would be named people."
http://mongoid.org/docs/documents.html
The documentation goes on to state that Mongoid uses a method called ActiveSupport::Inflector#classify to determine collection names, and provides instructions on how to specify the plural yourself.
Alternatively, you can specify the collection name in your class by including "store_in" in your class definition.
class Data
include Mongoid::Document
store_in :test
Hope this helps!