openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan Ireland" <eirel...@sybase.com>
Subject Byte array handling is probably not spec compliant - was RE: [jira] Resolved: (OPENJPA-422) Calendar objects contained in a detached Entity still have a "live" StateManagerImpl
Date Tue, 30 Oct 2007 19:35:33 GMT
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?

> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com] 
> Sent: Wednesday, 31 October 2007 2:38 a.m.
> To: dev@openjpa.apache.org
> 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 <eireland@sybase.com> 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:jira@apache.org]
> > > Sent: Sunday, 28 October 2007 9:22 a.m.
> > > To: dev@openjpa.apache.org
> > > 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.
> > >
> > >
> >
> >
> 


Mime
View raw message