Hi Mike,
actually I was using toplink in that example. I tried openJPA 1.0.1 and
you are right, there isn't problem with UPDATE before DELETE, on the
other hand openJPA does UPDATE on all managed entities even unchanged.
Toplink is little bit smarter in this particular thing.
Now it seems to me, that the best practice how to use JPA in my business
logic is, that every method (calling JPA internally) should create own
EntityManager and at the end of the method close it, or another approach
is to have one EntityManager for whole class (created in constructor)
and call clear at the end of method in my business logic.
Thank you
Bardolf
Michael Dick wrote:
Hi Bardolf,
I don't think there's a way to do a partial commit without detaching the
entities you don't want to update. The OpenJPAEntityManager interface
provides some utility methods which detach all entities in a collection,
which might make detaching a set of entities easier though.
Regarding the UPDATE and DELETE issue you're seeing, which version of
OpenJPA are you using? I ran a quick test with v 1.0.1 and I'm not seeing
that behavior.
-Mike
On Sun, Mar 23, 2008 at 12:09 AM, bardolf <[EMAIL PROTECTED]> wrote:
Hi Michael,
thank you for your response, it makes sense for me. My misunderstanding
came from wrong understanding of persist method. I wrongly assumed, that
the persist method provides functionality to store selected managed
objects.
I see now, that all managed objects are updated in DB during commit. Is
there any possibility to choose just objects I want to update (except
detaching object I don't want to update)?
When I call remove on a managed (and changed) object, why does UPDATE
get called before DELETE?
Thanks Bardolf
Michael Dick wrote:
Hi Bardolf,
In the example above you're using an application managed EntityManager.
Application managed EMs are considered extended persistence contexts by
default (ie the lifecycle of the persistence context can cross
transactions).
In this environment when you call EntityManager.find() a managed entity
will
be returned. Since the entity is managed any changes you make to it will
be
committed when you commit the transaction.
If you don't want the entity to be managed you can call
EntityManager.clear()
which detaches all entities or you can call
OpenJPAEntityManager.detach(myEntity)
to detach a single instance. The code might look something like this :
EntityManager em =
javax.persistence.Persistence
.createEntityManagerFactory("JavaApplication3PU").createEntityManager();
Address ad = em.find(Address.class,1);
ad.setMyProperty(xxx);
em.clear(); // detach all managed entities
// Detach a single entity
// OpenJPAPersistence.cast(em).detach(ad);
em.getTransaction().begin();
// if you decide you want the changes to be made after all uncomment
this
line
// ad = em.merge(ad);
em.getTransaction().commit();
I'm writing this from memory so this might not quite match up.
Hope this helps,
-Mike
On Fri, Mar 21, 2008 at 8:36 PM, bardolf <[EMAIL PROTECTED]> wrote:
Hi all,
I have following question. Why JPA call updates on all changed entities
during commit even though persist wasn't called.
[snip]
EntityManager em =
javax.persistence.Persistence.createEntityManagerFactory
("JavaApplication3PU").createEntityManager();
Address ad = em.find(Address.class,1);
ad.setMyProperty(xxx);
em.getTransaction().begin();
em.getTransaction().commit();
[/snip]
And even though I didn't call persist, changes are updated in database.
WHY???
Thanks B.
