thanks thiago, i'll look into that solution if i find i run into this again
On 30/10/2015 10:39 PM, Thiago H de Paula Figueiredo wrote:
On Thu, 29 Oct 2015 20:40:29 -0200, Paul Stanton
wrote:
further, it is not the 'save' that javassistifies the object, it is
'session.load' ! so if you do a
On Thu, 29 Oct 2015 20:40:29 -0200, Paul Stanton
wrote:
further, it is not the 'save' that javassistifies the object, it is
'session.load' ! so if you do a session.load(id) and a criteria.list()
which returns the same entity, the list will contain a javassisted
version of the object, whi
Mabet use an interface for the objects? Then the implementation class can
change all it wants to.
On Thu, Oct 29, 2015 at 11:40 PM, Paul Stanton wrote:
> further, it is not the 'save' that javassistifies the object, it is
> 'session.load' ! so if you do a session.load(id) and a criteria.list()
>
further, it is not the 'save' that javassistifies the object, it is
'session.load' ! so if you do a session.load(id) and a criteria.list()
which returns the same entity, the list will contain a javassisted
version of the object, which doesn't play nice with tapestry.grid. using
'get' instead of
Hi Thiago,
Using 'merge' instead of 'save' does not resolve the issue. I still have
to evict.
On 29/10/2015 11:04 PM, Thiago H de Paula Figueiredo wrote:
On Thu, 29 Oct 2015 07:23:07 -0200, Paul Stanton
wrote:
I have found an issue I believe with tapestery (grid component in
this case) wh
On Thu, 29 Oct 2015 07:23:07 -0200, Paul Stanton
wrote:
I have found an issue I believe with tapestery (grid component in this
case) where it cannot inspect details of hibernate 'enhanced' objects.
This happens when I save an object to the database and then query it out
again - the insta
Yes, it is necessary to 'evict' after 'save' to avoid this problem.
I'm not sure that this is ideal since it increases db io and code but it
works.
On 29/10/2015 8:23 PM, Paul Stanton wrote:
I have found an issue I believe with tapestery (grid component in this
case) where it cannot inspect d
