These are some changes currently being tested that will change the way mutations work. Please feel free to leave feedback and questions.
- Schema types preferred over suggested storage types.
Currently the logic for handling values without a schema type is to set them to string by default. But this created an issue of types overshadowing other types like passwords. This is specially true with JSON values as strings are used regularly. The new logic will prefer the schema type, if defined, over a default or suggested type. New type assignment logic: schema type → suggested type → default type
Example 1.1 - Schema type vs suggested type
// schema
age: int .
// mutation
{
set {
_:x <age> "13"^^<xs:string> .
}
}
// query response, notice age is JSON number not a string.
{
"data": {
"q": [
{
"age": 13
}
]
}
}
- Stricter password type
The password type only can be assigned with schema. Once set, it can’t be changed or suggested to any other type. Similarly, other types may not be changed to password, such as string.
Example 2.1 - From password to x.
// schema
secret: password .
// alter
secret: string .
// response
{
"errors": [
{
"code": "Error",
"message": "Schema change not allowed from PASSWORD to STRING"
}
]
}
Example 2.2 - From x to password.
// schema
another: string .
// alter
another: password .
// response
{
"errors": [
{
"code": "Error",
"message": "Schema change not allowed from STRING to PASSWORD"
}
]
}
- Type-hinting for default values
As mentioned in #1 values without a known schema type are set to string by default. A new type-hinting heuristic will try to determine the best likely type for the value and suggest it. If you don’t want this, simply create a schema.
Example 3.1 - No schema specified for the values below (JSON)
{
"set": [
{
"bool1": "true",
"bool2": "false",
"bool3": "TRUE",
"bool4": "FALSE",
"bool5": "True",
"bool6": "False",
"date1": "2018-10",
"date2": "2018-10-03",
"int1": "123",
"int2": "-321",
"float1": "3.14",
"float2": "-9.8",
"float3": "1e-2",
"float4": "1e10"
}
]
}
Export to inspect types:
<_:uid1> <bool4> "false"^^<xs:boolean> .
<_:uid1> <int1> "123"^^<xs:int> .
<_:uid1> <bool5> "true"^^<xs:boolean> .
<_:uid1> <bool6> "false"^^<xs:boolean> .
<_:uid1> <bool3> "true"^^<xs:boolean> .
<_:uid1> <float2> "-9.8"^^<xs:float> .
<_:uid1> <bool1> "true"^^<xs:boolean> .
<_:uid1> <date1> "2018-10-01T00:00:00Z"^^<xs:dateTime> .
<_:uid1> <bool2> "false"^^<xs:boolean> .
<_:uid1> <float1> "3.14"^^<xs:float> .
<_:uid1> <int2> "-321"^^<xs:int> .
<_:uid1> <float4> "1E+10"^^<xs:float> .
<_:uid1> <float3> "0.01"^^<xs:float> .
<_:uid1> <date2> "2018-10-03T00:00:00Z"^^<xs:dateTime> .
- Float value changes
Currently all float values were being stored with exponent such as 123E+00. This has an inherent limitation how floats are handled, both internally and by users. Now exponents are used only when justifiable by the decimal. ie., Also, added support for floats with exponents.
Current:
123.3 is formatted as 1.233E+02
100000000.0 is 1E+08
1e9 is "1e9"
Change:
123.3 as is 123.3
100000000.0 is 1E+08
1e9 is 1E+09