Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Field path handling makes no distinction between a.[] and a #627

Open
wilkinsona opened this issue Jun 21, 2019 · 0 comments
Open

Field path handling makes no distinction between a.[] and a #627

wilkinsona opened this issue Jun 21, 2019 · 0 comments

Comments

@wilkinsona
Copy link
Member

wilkinsona commented Jun 21, 2019

In working on #626, it has become apparent that the lack of distinction that is made between a.[] and a is problematic. It's a subtle difference, but the former should locate the contents of the array at a, whereas the latter should locate the array itself.

The following tests illustrate the problem:

@Test
public void typeForArrayWithMixedContents() {
	Object fieldType = new JsonContentHandler("{\"a\": [\"five\", 5]}".getBytes())
			.resolveFieldType(new FieldDescriptor("a"));
	assertThat(fieldType).isEqualTo(JsonFieldType.ARRAY);
}

@Test
public void typeForContentsOfArrayWithMixedContents() {
	Object fieldType = new JsonContentHandler("{\"a\": [\"five\", 5]}".getBytes())
			.resolveFieldType(new FieldDescriptor("a.[]"));
	assertThat(fieldType).isEqualTo(JsonFieldType.VARIES);
}

The first test passes but the second test fails. It fails because the resolved type is ARRAY rather than VARIES.

When a payload is an array at the top level, [] is currently used to locate that array. To correct the behaviour of the test above, it would change to locating the contents of the array. This change would require the introduction of another syntax that identifies the root of the payload. An empty path is one option, another would be $. The latter would align with JSON path which uses $ to refer to the root element.

While the current behaviour is a bug, fixing it will be a breaking change for some so a balance needs to be struck. Waiting until 2.1 feels like the best approach at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant