#48 When querying getItem or getItems with a strongly typed class, automatically add a query filter for system type #55
Conversation
…tomatically add a query filter for system type
| ((DeliveryOptions) deliveryOptionsField.get(client)).setProductionEndpoint(testServerUri); | ||
|
|
||
| ArticleItem itemObj = client.getItem("on_roasts", ArticleItem.class); | ||
| Assert.assertNotNull(itemObj); |
There was a problem hiding this comment.
the tests are not conclusive. they'd pass even if the new type detection logic was not present because you're filtering by codename in the first place.
There was a problem hiding this comment.
Ultimately, the test hits a mocked server, which limits it's usefulness for the edge you are bringing up, but the mock server is checking for the parameter to be present. I would expect that in a real world scenario, if you filtered by system.type=article, and codename=some_non_article, that the API wouldn't respond with any results, correct?
There was a problem hiding this comment.
This test hits the view a content item API, which requires a code name: https://developer.kenticocloud.com/v1/reference#view-a-content-item
There was a problem hiding this comment.
correct. 👍 i didn't notice the check on the mocked server. merging
|
the implementation is ok, I found just one little thing in the tests.. |
This is a convenience enhancement to automatically add the system.type query parameter if it's possible by introspecting the type requested.
Internally, we have been finding many times we are manually adding this to our client request parameters, as sometimes certain queries will return content types that somewhat map to the objects we request, and are not wanted.