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
Labels

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.

@wilkinsona wilkinsona added the type: bug A bug label Jun 21, 2019
@wilkinsona wilkinsona added this to the 2.1.0.RC1 milestone Jun 21, 2019
@wilkinsona wilkinsona self-assigned this Jun 21, 2019
@wilkinsona wilkinsona removed this from the 2.1.0-RC1 milestone Mar 24, 2022
@wilkinsona wilkinsona removed their assignment Oct 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant