5.8.2.3 Data Type Handling

5.8.2.3.1 User Data Types

5.8.2.3.2 Data Type Resolution

In general, the data type of an argument is resolved using the following criteria, in order of priority:

• The expected data type for the target parameter.

• The data type of the value based on the JSON specification.

• User specified data type.

The last case is a complicated (and rare) case applicable for named arguments only. For example, suppose you have a MySQL Shell Plugin function such as:

def set_object_attributes(variables)

Where variables is a dictionary with no predefined set of values, thus it accepts any key, and therefore accepts any data type for the value. To set a string attribute named streetNumber with a string value of 123, issue:

$ mysqlsh -- plugin set-object-attributes --streetNumber=123

Because there is no expected data type, the value 123 is interpreted as a numeric value according to the JSON specification, but we wanted to store that as a string, not as a number.

Note

Currently there is no case of an API function like this unless user creates a plugin as explained above.

5.8.2.3.1 User Data Types

To avoid issues with MySQL Shell trying to guess the type of input data, the command-line integration supports forcing a specific data type, by specifying a named argument using the following syntax:

--key:type=value

Where type is one of:

• str

• int

• uint

• float

• bool

• list

• dict

• json

To store the value as a string, issue:

$ mysqlsh -- plugin set-object-attributes --streetNumber:str=1234

Important

This format is allowed in any named argument, but it is only required when there is no expected data type for the argument. If there is an expected data type for the parameter and you specify a different data type, an error is raised.

5.8.2.3.2 Data Type Resolution

When you do not specify the data type, MySQL Shell attempts to resolve the data type using the following logic. This data interpretation logic is based on the JSON specification but has some MySQL Shell specific additions and limitations:

• Strings:

  • Support both double quoted and single quoted strings.

  • Support for hexadecimals such as \xNN where NN is a hexadecimal digit. This is used to represent ASCII characters in hexadecimal format.

  • Support for vertical tabs escaped character

• The following literals can also be defined:

• undefined: define a value as undefined (not really needed in CLI so usage is discouraged).

• true/false: creates a boolean value.

• null: define a null value.

Any value not covered by the JSON specification and the rules above is interpreted as a plain string.