PersistentEntityDao JPA compliance

22 views
Skip to first unread message

Vojtech Szocs

unread,
May 14, 2009, 4:07:50 AM5/14/09
to DAO Fusion
Hi guys, I was browsing through the EJB 3.0 / JPA specification
recently and I noticed that one of our PersistentEntityDao methods is
named and actually implemented using Hibernate-specific operation:

public <S extends T> S saveOrUpdate(S entity);

Method implementation:

getSession().saveOrUpdate(entity);
return (S) getSession().merge(entity);

This method therefore triggers SAVE_UPDATE and MERGE cascade types
(note that SAVE_UPDATE is Hibernate-specific too). saveOrUpdate()
comes historically from times when DAO Fusion was directly bound to
Hibernate.

To make PersistentEntityDao fully compliant to JPA specification, I
would recommend to break saveOrUpdate() into two methods: persist()
and merge(). Following image depicts the standard JPA entity life
cycle:
http://java.boot.by/scbcd5-guide/images/060100.gif

Second task would be to actually test corresponding JPA cascade types
(PERSIST and MERGE) in core integration tests (we might test other
cascades as well if necessary).

What's your opinion?

huss...@gmail.com

unread,
May 18, 2009, 12:21:08 AM5/18/09
to DAO Fusion
I agree that breaking saveOrUpdate() into two methods is good. Because
I think explicit is better than implicit.
To make thing be too comfortable by changing the internal operation to
detect the object that it is
new or not may be not the good idea; in addition, the normal web
operation that I've seen use separate method
for update and create.

Hus

vojtec...@gmail.com

unread,
May 18, 2009, 11:21:16 AM5/18/09
to DAO Fusion
I agree with that, plus, as far as I know, saveOrUpdate() uses
proprietary logic to detect whether the entity is new (transient) or
attached (persistent).

You can see how Hibernate detects the entity state at
AbstractSaveEventListener#getEntityState() - note the "try interceptor
and unsaved-value" comment and associated call to
ForeignKeys#isTransient(). This essentially results in possible
database access _before_ the entity is actually persisted/updated :-)

"The merge operation is clever enough to automatically detect whether
the merging of the detached instance has to result in an insert or
update."
http://forum.springsource.org/archive/index.php/t-36064.html

Vojtech
Reply all
Reply to author
Forward
0 new messages