Evan, On 10/30/07, Evan Ireland <[EMAIL PROTECTED]> wrote: > > Kevin, > > JPA 1.0 section 3.2.3 Synchronization to the Database > > ... > > An update to the state of an entity includes both the assignment > of a new value to a persistent property or field of the entity > as well as the modification of a mutable value of a persistent > property or field. > > If you have to call the setter method again in order for the > change to be detected, surely this would not be spec-compliant. > > Should we report this as a bug?
No, because byte[], Byte[], char[], and Character[] are considered immutable types. Kevin > -----Original Message----- > > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 31 October 2007 2:38 a.m. > > To: [email protected] > > Subject: Re: [jira] Resolved: (OPENJPA-422) Calendar objects > > contained in a detached Entity still have a "live" StateManagerImpl > > > > Evan, > > > > On 10/28/07, Evan Ireland <[EMAIL PROTECTED]> wrote: > > > > > > Since you appear to be familiar with the proxying stuff, I > > wonder if > > > you can say, for persistent attributes of type "byte[]" > > which cannot > > > be proxied, but are mutable, how does OpenJPA handle that case? > > > > > > As one big blob of data... :-) If you modify the > > individual byte array > > contents, then you will have to re-set the array into your > > persistence field in order for the change to be detected. > > > > OpenJPA also provides the ability to define a customized type > > plugin which might allow you to define and detect a byte[] > > modification, but I'm not totally familiar with this aspect > > to know if it would help your situation or not. > > > > Kevin > > > > > > > > > > > -----Original Message----- > > > > From: Kevin Sutter (JIRA) [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, 28 October 2007 9:22 a.m. > > > > To: [email protected] > > > > Subject: [jira] Resolved: (OPENJPA-422) Calendar objects > > contained > > > > in a detached Entity still have a "live" StateManagerImpl > > > > > > > > > > > > [ > > > > https://issues.apache.org/jira/browse/OPENJPA-422?page=com.atl > > > > assian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > > > > > > > Kevin Sutter resolved OPENJPA-422. > > > > ---------------------------------- > > > > > > > > Resolution: Fixed > > > > > > > > Resolved for 1.0.1 and 1.1.0 via svn revision 589207. > > > > > > > > > Calendar objects contained in a detached Entity still > > have a "live" > > > > > StateManagerImpl > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > > -------------- > > > > > > > > > > Key: OPENJPA-422 > > > > > URL: > > > > https://issues.apache.org/jira/browse/OPENJPA-422 > > > > > Project: OpenJPA > > > > > Issue Type: Bug > > > > > Components: kernel > > > > > Affects Versions: 1.0.0 > > > > > Reporter: Kevin Sutter > > > > > Assignee: Kevin Sutter > > > > > Fix For: 1.0.1, 1.1.0 > > > > > > > > > > > > > > > When Entities are detached, normally the StateManagerImpl > > > > instance associated with this Entity is replaced with a > > > > DetachedStateManager. Not only with the Entity itself, but also > > > > with the proxied attributes (Date, Calendar, Collection, and Map > > > > types). But, somehow the Calendar object type was > > forgotten in the > > > > code for this processing. So, the Calendar proxy type > > was left with > > > > a "live" StateManagerImpl instance. > > > > If the owning Broker (EntityManager) for this Entity was closed, > > > > then the use of this "live" StateManagerImpl would end up with an > > > > IllegalStateException. And, even if the owning Broker > > > > (EntityManager) was still open, this "live" > > > > StateManagerImpl should not have been tracking the state > > since the > > > > enclosing Entity was detached. > > > > > A simple one-line update to > > > > DetachManager$DetachFieldManager.reproxy() method will > > now process > > > > the Calendar proxies as well as the other proxies it was already > > > > doing. > > > > > > > > -- > > > > This message is automatically generated by JIRA. > > > > - > > > > You can reply to this email to add a comment to the issue online. > > > > > > > > > > > > > > > > > >
