DATAREST-739 Using different projection for each entity subtype #210
+3,247
−1,082
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'm a new contributor. ICLA confirmation code 168920160323094307. |
|
Please can you merge? |
Instead of replacing the HAL Browser's browser.html, take the existing one and alter it inside the build job. This ensures that future updates don't break so horribly. Related to mikekelly/hal-browser#89 which will provide an explicit token to match, instead of using the closing `</body>` tag.
Minor formatting in pom.xml of the HAL Browser module.
Fix typo "returnBodyOnupdate" -> "returnBodyOnUpdate". Original pull request: spring-projects#242.
The serializer for projection resources now also invokes ResourceProcessor instances registered for that particular projection. Original pull request: spring-projects#238.
Original pull request: spring-projects#238.
Original pull request: spring-projects#244.
We now don't prematurely drop fields that don't have a persistent property exposed in DomainObjectReader. Doing so dropped values for transient fields as the latter are not exposed as persistent property in the first place. We still skip any nested merging though. Original pull request: spring-projects#240.
Moved the newly added test case to the end of the list. Formatting. Original pull request: spring-projects#240.
… resolvers. Original pull request: spring-projects#232.
We now support nested Sort properties considering Jackson mapping. Sort translation is optional and skipped if the domain class is not resolvable. Translation in the scope of a domain class maps property paths to apply sorting using embedded properties.
A sort string `nested-name` resolves to a property path `anotherWrap.embedded.name`.
class Aggregate {
@JsonUnwrapped
public UnwrapEmbedded anotherWrap;
}
class UnwrapEmbedded {
@JsonUnwrapped(prefix = "nested-")
public Embedded embedded;
}
class Embedded {
public String name;
}
Original pull request: spring-projects#232.
Minor code reorganizations. Eagerly create SortTranslator to avoid repeated instantiation. Original pull request: spring-projects#232.
…new instances. Original pull request: spring-projects#241.
Formatting and author. Original pull request: spring-projects#241.
Seems the change for DATAREST-938 has also fixed this one. Added a test case similar to what was provided in the example for the original ticket.
…val for PUT requests. DomainObjectMerger now properly adds and removes elements to and from collections. Original pull request: spring-projects#245.
Some tiny refactorings in DomainObjectReader. We're now using TypeInformation instead of Class to preserve more generics information when it comes to deeper nesting. Moved some code around in the unit tests. Original pull request: spring-projects#245.
Fixed broken equals(…) in ProjectionDefinition. Switched to iterating over Map's entry set instead of the keys. Made UriAwareHttpServletRequest static.
…nd consider ETag and Last-Modified headers. We now interpret If-None-Match and If-Modified-Since headers on requests to resources backed by query methods returning a single instance only. This allows clients to optimize GET requests to those resources to save bandwidth.
…istently. Adapted the return type of setter methods in RepositoryRestConfiguration to consistently return the current instance to allow call chaining.
Original pull request: spring-projects#246.
Skip all merge logic if the source value is null. That frees all nested logic from handling with that case and us falling back to plain Jackson reading. The array handling now also opts out if the source value is not a collection or array in the first place as it means we need to let Jackson override the value with the collection given to be deserialized. Original pull request: spring-projects#246.
…RestMvcConfiguration.
We now issue the user registration of Jackson modules before any of the default modules Spring Data registers get applied. Testing module registration seems to be rather difficult as Jackson doesn't actually expose API to do so. An issue [0] was filed for Jackson to improve on this. [0] FasterXML/jackson-databind#1478
koscejev
force-pushed
the
issue/DATAREST-739
branch
from
8b869e2
to
039a908
Compare
|
Thanks @Dodecaedro for rebase. |
|
Thanks to you for your work on it. Now could someone please merge the pull request? Thank you. |
|
According to the author this PR "required a lot of changes to existing structure of Jackson2 serialization module, as well as introduction of a new field to support the projection hierarchy, so it's not clear when this will be merged." |
spring-projects-issues
added
the
status: waiting-for-triage
odrotbohm
force-pushed
the
main
branch
3 times, most recently
from
63ac127
to
cfb7079
Compare
|
Hi, thank you @koscejev for the work on the subject ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What took the most time and effort weren't sub-projections, but actually trying to properly support serialization with type information, considering the usage of resource wrappers and projections. I've created multiple tests for the modified parts (there have been almost no tests before), but it's possible to do more tests still, since the underlying Jackson serializer behavior can be quite complicated.
Now each projection can have
@JsonTypeInfospecified (see tests), which will override the same annotation on the projected target class. However, this only works as long as@JsonTypeInfodoesn't specifyuse = JsonTypeInfo.Id.NONE. This is because this case is indistinguishable (based on Jackson behavior) from not specifying@JsonTypeInfoat all, so it's not possible to use this to "disable" type info for projections. I can imagine this could be a problem for someone who wants to use a projection to disable type information on projected classes...