Materialized views return array fields with the wrong type.

[fredcarle]

This was found due to a potential test gap.

When the view is materialized, the returned array fields are of the wrong type as described by the test bellow.

func TestView_SimpleWithSizeConstraint_MaterializedView_DoesNotErrorOnSizeViolation(t *testing.T) {
	test := testUtils.TestCase{
		SupportedViewTypes: immutable.Some([]testUtils.ViewType{
			testUtils.MaterializedViewType,
		}),
		Description: "Simple view with size constraint",
		Actions: []any{
			testUtils.SchemaUpdate{
				Schema: `
					type User {
						name: String
						pointsListInt: [Int!]
						pointsListFloat32: [Float32!]
						pointsListFloat64: [Float64!]
					}
				`,
			},
			testUtils.CreateView{
				Query: `
					User {
						name
						pointsListInt
						pointsListFloat32
						pointsListFloat64
					}
				`,
				SDL: `
					type UserView @materialized(if: false) {
						name: String
						pointsListInt: [Int!]
						pointsListFloat32: [Float32!]
						pointsListFloat64: [Float64!]
					}
				`,
			},
			testUtils.CreateDoc{
				Doc: `{
					"name":	"Alice",
					"pointsListInt": [1, 2, 3],
					"pointsListFloat32": [1, 2, 3],
					"pointsListFloat64": [1, 2, 3]
				}`,
			},
			testUtils.Request{
				Request: `
					query {
						UserView {
							name
							pointsListInt
							pointsListFloat32
							pointsListFloat64
						}
					}
				`,
				Results: map[string]any{
					"UserView": []map[string]any{
						{
							"name": "Alice",
							"pointsListInt":     []any{float64(1), float64(2), float64(3)},
							"pointsListFloat32": []any{float64(1), float64(2), float64(3)},
							"pointsListFloat64": []any{float64(1), float64(2), float64(3)},
						},
					},
				},
			},
		},
	}

	testUtils.ExecuteTestCase(t, test)
}

[AndrewSisley]

I'm not sure this is specific to Views, and I'm not sure we want to do anything about this.

Constraints such as Size can vary across nodes, and across definition versions within nodes. This means that we can never ensure that the constraint is respected beyond the initial document mutation - we will always have a system that permits values to breach their constraints, unless we block definition patches that cause values to breach them (e.g. by reducing size) and either prevent either the syncing of breaching documents over P2P or hide documents that breach the limits at query time.

I think limiting constraints to mutation time only (as they are currently) is the lesser evil, perhaps at some point we could allow systems to opt in to more aggressive enforcement, but I would expect that to be a fairly low-priority feature given the downsides of enabling it.

@fredcarle I suggest renaming this ticket, and adding a test or two documenting this and linking them to this issue

EDIT: I see you have added the tests in your current PR, it might be worth making that clearer in this issue - I read the inline test as one that only existed in this issue, not committed code.

[fredcarle]

Having a constraint in the test described above might have led to focusing on the wrong thing. This issue is the returned types for the array fields on the query.

[jsimnz]

Just to add context for posterity regarding what Andy initially wrote.

I've mentioned this before and I think there's context in an issue somewhere but as a general blanket statement global constraints and CRDTs don't mix well at all.

Any constraint we put on schema fields likely will only ever be for the local nodes POV.

This can be seen in a simple example of a max value constraint on a counter CRDT field, if we way the max is 10, and two nodes each increment by 6, when tho locally this is a valid operation, together when merged they are invalid.

(Not to hijack this issue ;) )