On Thu, 12 Feb 2015 09:58:53 -0200, Poggenpohl, Daniel
<daniel.poggenp...@isst.fraunhofer.de> wrote:
Hi,
Hi!
thanks for your help. I still have some questions (and will probably
change the primary key to a non-compound one).
tapestry-hibernate doesn't support compound primary keys out-of-the-box.
My project depends on "tapestry-jpa", because we didn't want to
introduce any hibernate-specific implementations. Although the
persistence provider is still hibernate, using a dependency to
"hibernate-entitymanager".
As far as I know, tapestry-jpa is basically a copy-and-past from
tapestry-hibernate, but adapted to use EntityManager instead of Session
and stuff like that.
What I'm wondering just now is if this could cause any problems doing it
this way?
No. Tapestry-JPA also doesn't support compound primary keys out-of-the-box.
Another recommendation: avoid using @Persist, even more in components.
Why should I avoid it? Does it produce bugs, slow performance or high
memory consumption?
@Persist, in general, causes a higher memory usage, which leads to slower
performance. It can also produce bugs, specially with Hibernate or JPA
entities.
You're invoking session.merge().
Am I understanding you correct that EntityManager.merge() using
hibernate as the persistence provider is a wrapper around
Session.merge(), which is hibernate-specific?
Yes, but in this case, both merge() methods work in the same way.
And do you mean that the entity hasn't been persisted in this session
and therefore it is perceived as transient?
You're correct.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
