Testing: Mutation type changes

mutation

(Gus) #1

These are some changes currently being tested that will change the way mutations work. Please feel free to leave feedback and questions.

  1. 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
      }
    ]
  }
}
  1. 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"
		}
	]
}
  1. 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> .
  1. 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

(Billy Lindeman) #2

Sent here from: https://github.com/dgraph-io/dgraph/issues/2735.

@manishrjain This is a breaking change for us, and I’m pretty disappointed in how such an oversight for JSON mutations could be introduced without even being mentioned in the release notes (or docs) :\

@srfrog While "1" == 1 is true in javascript, "1" === 1 is false, which is how you should check equality with types considered.

It seems to me that if you WANT a type conversion from string to something else THAT would be a case where defining a schema makes sense. Defining a schema to keep a string a string is backwards.

Lets say you have a field zip_code (just one of our cases where things break). We take care to make sure all zip codes are string types, but now if the first zip code is a US zip code, the schema is broken. Our application has an evolving schema, and this now breaks the ability to evolve the schema with user added fields.

I apologize for my curt tone, but it is incredibly frustrating to have such a drastic change added to a major release without mention, and such a flippant response as “just add a schema.”

At the very least it seems like this should be a configurable option.