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

Retrieve the database object when posting an entity #34

Open
xfrancois opened this issue Aug 8, 2019 · 3 comments
Open

Retrieve the database object when posting an entity #34

xfrancois opened this issue Aug 8, 2019 · 3 comments

Comments

@xfrancois
Copy link

xfrancois commented Aug 8, 2019

Hello,
When posting an entity with Bowman, the post method returns the entity with the resource id field populated via reflexion. However, if there are fields which are directly populated by the database (an auto-increment for example)n the field won't be filled in Bowman.
It's easy to bypass this problem by doing something like this :

 public MyEntity postMyEntity(final MyEntity myEntity) {
        URI myEntityURI= myEntityClient.post(myEntity);
        return myEntityClient.get(myEntityURI);
    }

I guess it could be usefull to implement something like this directly in Bowman ? What do you think ?

Thank you for this awesome library !

@hdpe
Copy link
Owner

hdpe commented Aug 23, 2019

Hi,

Thanks for raising this, and sorry for the delay getting back.

You're right that currently post ignores the response body and just mutates the passed entity to populate the ID and returns that ID.

This is inconsistent, because patch currently returns the response body as an entity, and put just returns void...

I think it would be good to make this clear and consistent between the methods. For example, maybe something like:

  • void post(T entity)

  • URI postForId(T entity)

  • T postForEntity(T entity)

  • void put(T entity)

  • T putForEntity(T entity)

  • void patch(T entity, Object patch)

  • T patchForEntity(T entity, Object patch)

What do you think? Obviously this would be a pretty extremely breaking change.

On the other hand, JPA doesn't feel the need for these overloads on the EntityManager. What happens, for example, if you persist an entity with JPA and a database trigger updates one of its fields? Would you expect the entity to be mutated accordingly? Or would you expect to have to reload the entity? Following this reasoning, your workaround looks fine.

Thanks

@xfrancois
Copy link
Author

Hi,
I agree for the consistency between the CRUD methods, I think it will be less confusing, your propositions for the methods seem great !
I think your case is quite similar to the auto-increment case. So if I do a postForEntity, I will expect a reloading internally (maybe like I did with my workaround). However, I don't know if my expectations are standards, do you think it's a bad practice ?

@hdpe
Copy link
Owner

hdpe commented Sep 4, 2019

I'm not suggesting that postForEntity would do any sort of reloading from the client end, but that you could use this method if the server returned the entity as the response body, and the client would then honour that. With the current post method the response body is just discarded. I believe Spring Data REST returns the created entity as the response body following a POST.

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

No branches or pull requests

2 participants