Forums Register Login

Why EntityManager.refresh, and EntityManager.remove require attached entity?

+Pie Number of slices to send: Send
Why don't they make the entity be attached if needed? Is there any design issues prevent that?

I think it doesn't make sense that if I want to refresh, or remove I need to merge first, and merging is updating, right?
Moreover, I think it's very confusing that to refresh or remove I need to call merge *to update the entity first*( before I can refresh (reset) or remove it.

There is no point to merge (update) if I want to refresh or remove an entity.
+Pie Number of slices to send: Send
for entitymanager.refresh, you can retached an entity which was detached

for entitymanger.remove, you have to make sure the entity must be attached before you remove it
+Pie Number of slices to send: Send
 

Why don't they make the entity be attached if needed? Is there any design issues prevent that?


It won't be tough for container provider to implement it. But container provider (entity manager implementor) need to follow what spec says to them.

I think it doesn't make sense that if I want to refresh, or remove I need to merge first, and merging is updating, right? Moreover, I think it's very confusing that to refresh or remove I need to call merge *to update the entity first*( before I can refresh (reset) or remove it.
There is no point to merge (update) if I want to refresh or remove an entity.


I had same doubt in this thread, and I was answer by Ralph Jaus that requirement is entity should be attached before refresh/ remove is called and that is possible by calling find() before refresh/ remove is called
em.refresh(em.find(Item.class, item.id));




+Pie Number of slices to send: Send
 

jim li wrote:for entitymanager.refresh, you can retached an entity which was detached

for entitymanger.remove, you have to make sure the entity must be attached before you remove it


I know, jim, and my question is "why"
+Pie Number of slices to send: Send
 

Deepika Joshi wrote:

Why don't they make the entity be attached if needed? Is there any design issues prevent that?


It won't be tough for container provider to implement it. But container provider (entity manager implementor) need to follow what spec says to them.


I think it's easy to implement, but is this a problem in JPA spec or there is a merit behind these awkward to use API?
If this is a problem in the spec, is there a plan to improve in the next version?

Deepika Joshi wrote:

I think it doesn't make sense that if I want to refresh, or remove I need to merge first, and merging is updating, right? Moreover, I think it's very confusing that to refresh or remove I need to call merge *to update the entity first*( before I can refresh (reset) or remove it.
There is no point to merge (update) if I want to refresh or remove an entity.


I had same doubt in this thread, and I was answer by Ralph Jaus that requirement is entity should be attached before refresh/ remove is called and that is possible by calling find() before refresh/ remove is called
em.refresh(em.find(Item.class, item.id));


Thanks, but I am still not satisfied, because I think it should be like em.fresh(item), em.remove(item)
And then the entire population worshiped me like unto a god. Well, me and this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 2567 times.
Similar Threads
EJB 3 IN ACTION - EntityManager merge() and refresh() method conflict
JPA Refresh Query from EJB3 In Action
Hibernate: merge more than once causes OptimisticLockException
Entitymanager.refresh doubt
a question regarding chap 9 ejb3 in action
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 06:08:05.