spring-data-rest
spring-data-rest copied to clipboard
spring-projects
Unable to update associated resource using PUT request on the item resource [DATAREST-1001]
Joseph Valerio opened DATAREST-1001 and commented
When I create an entity with a FK to another entity, all is good, but when I try to updated that relationship it has no effect
Affects: 2.6 GA (Ingalls), 2.5.7 (Hopper SR7)
Attachments:
- test.tar.xz (18.18 kB)
Issue Links:
- DATAREST-1000 PUT on Entity with OneToOne/ManyToOne doesn't update (PATCH works) ("is duplicated by")
11 votes, 16 watchers
Oliver Drotbohm commented
Please add information about your domain objects, repositories, and the interaction you have with the service. Ideally in a tiny sample project whose tests I can just run to see them fail
Joseph Valerio commented
You beat me to the punch. Here is a working example of the defect.
https://github.com/joevalerio/DATAREST-1001
This is related to the fix for DATAREST-944. I submitted a fix for 944 that does not suffer from this defect, but have not had the time to look into your implementation.
Thanks in advance,
- Joe
Oliver Drotbohm commented
I looked into this and I'd argue you're expecting things to work in a way they don't work. PUT requests don't consider associations to linkable resources, i.e. related resources that are pointed to by links. The reason for that is two-fold:
- If we consider URIs for association fields in the payload to update those associations, the question comes up about what's supposed to happen if no URI is specified. With the current behavior, linked associations are simply not a part of the payload as they only reside in the
_linksblock. We have two options in this scenario: wiping the associations that are not handed, which breaks the "PUT what you GET" approach. Only wiping the ones that are supplied usingnullwould sort of blur the "you PUT the entire state of the resource". - For all the reasons mentioned in 1. there are dedicated assoctiation resources exposed that can be manipulated directly.
So it looks like that if you want to change both state of the resource plus associations at the same time, I guess exposing a dedicated resource to do that is the way to go
Joseph Valerio commented
I can understand your stance, but prior to spring-data-rest-webmvc-2.5.7.RELEASE, this WAS how it worked (change the version of spring-data-rest-webmvc to 2.5.6.RELEASE on the example I provided to see the test pass). So I am assuming during the fix for DATAREST-944 this functionality was removed, intentionally or not. I would regret having to write custom resources just to manage an atomic update to a resource. I would hope SDR could provide a way to do this.
Please reconsider.
Joseph Valerio commented
One final plea here. When we Post a resource with a required FK reference, we set the property value as a URI, matching the semantics I would like to preserve for POST/PATCH. I understand there is some ambiguity, but that is what documentation is for. Personally, I like the notion of having to explicitly set it to null even on a PUT, to preserve PUT what you GET. This would not change the ability to update the linked resources via their dedicated association resources urls
Adam Kučera commented
From my perspective, it is a strange behaviour when you PUT a resource with new link to an associate resource, but it does not get updated. (without any sign of an error). Does not look like "PUT what you GET" approach then.
We had additional discussion on this topic in https://stackoverflow.com/questions/45620195/spring-data-rest-put-request-does-not-work-properly-since-v-2-5-7/45831955
Sergey Burmin commented
Have the same issue after updating our application to SDR 2.6.8. Many convincing arguments have been advanced for fixing this problem. Can you provide any feedback about?
Guram Savinov commented
If you want to update state of the resource and associations, PATCH requests do exactly what you want.
For example:
PATCH to http://localhost:8080/api/users/3
{ "name": "Some user name", "address": "http://localhost:8080/api/addresses/4" }
Why this feature isn't mentioned in documentation? Is it legal to update associations via PATCH resource itself instead of dedicated URL like http://localhost:8080/api/users/3/address with uri-list request type?
cyril-gambis commented
After quite a lot of researches, I arrived on this Jira ticket.
I can understand Oliver Drotbohm point of view; would it be possible to have some examples about the best practice to update an entity and its associations ?
For instance, if I have a "User" entity with "adresses" as an attribute (@manytomany relationship), what would be the good way to update the adresses of a user?
Using PATCH instead of PUT directly on the user resource?
Or using PATCH with uri-list on the association (like .../users/4/adresses", like answered here: https://stackoverflow.com/questions/29898692/posting-to-a-collection-association-using-spring-data-rest
copy/paste from stackoverflow:
Add multiple devices to an existing collection: {{curl -i -X PATCH -H "Content-Type: text/uri-list" -d " http://localhost:8080/app/device/2 http://localhost:8080/app/device/3" http://localhost:8080/app/group/87/devices}}
sante85 commented
test.tar.xz
i edit this in spring data jpa test
and resul test is in error
@Test // DATAREST-523public void augmentsOneToManyCollectionAssociationUsingPost() throws Exception {
List<Link> links = preparePersonOrderResources(new Person("Frodo", "Baggins"), new Order(), new Order());
Link frodosSiblingsLink = links.get(0).expand(); Link bilboLink = links.get(1);
for (int i = 1; i <= 2; i++) {
mvc.perform(post(frodosSiblingsLink.getHref()).// content(bilboLink.getHref()).// contentType(TEXT_URI_LIST)).// andExpect(status().isNoContent());
mvc.perform(get(frodosSiblingsLink.getHref())).// andExpect(jsonPath("$._embedded.people", hasSize(i))); } }
teicher commented
while we understand the necessity for this, it's a big showstopper that this isn't mentioned anywhere in the docs (that I could find).
I would have expected that at 4.3.1 at the PUT and PATCH descriptions
AlekseiG commented
I don't agree that current behaviour is correct. From RFC 2616 documentation I see that the main idea of PUT is: The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. So my clients are expecting same reaction for PUT and POST. If clients can create association between two resources using POST, so it must works for PUT also.
I understand difficulties from Oliver's comment, but it doesn't mean that nothing must be changed. Associations from User to Address it is user.address_id on database level, so I want to create USER with this association using POST/PUT. Without this functionality PUT is useless and can update only simple fields.
"PUT what you GET" contradicts that "PUT must include POST functionality", and second point is more important as for me...
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
+1.
https://github.com/spring-projects/spring-data-neo4j/issues/2500#issuecomment-1072693790
Here are all the very useful details you'd need to investigate the issue. Feel free to ask me anything in order to solve it.
