Re: [jira] Resolved: (OPENJPA-43) update of a persistent field using a @Lob annotation is not being marked dirty

2006-09-14 Thread Marc Prud'hommeaux


We might just be being too clever here ... if a field is set, but  
oldvalue==newvalue, then we don't mark it dirty. That obviously  
breaks down for cases like this, where we can't perform dirty  
tracking on the opaque blob.


You might need to resign yourself to either having an intermediate  
null setting, or else manually calling OpenJPAEntityManager.dirty()  
on the field to make sure the system knows that it has changed. You  
can always make your setter perform the additional intermediate null  
setting.





On Sep 14, 2006, at 12:29 PM, David Wisneski wrote:


that works.
   Address a = e.getHome();
   a.setCity(NewCity);
   e.setHome(null);
   e.setHome(a);

Also if I create a new instance of Address as in
  Address newa = new Address();
   e.setAddress(newa);

Both of the above work.

But doing an update with making a new copy of the Adresss does not  
work for

me.
  e.setHome( e.getHome().setCity(NEW));

Do I have to override equals on the Address ?


On 9/14/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:


David-

 There was a typo in my code.  But even doing this, the update is
 not being
 written back to the database at commit or flush.

That's a little surprising.

What happens if you do this:

Blob home = e.getHome();
home.setStreet(new value);
e.setHome(null);
e.setHome(home);




On Sep 14, 2006, at 11:31 AM, David Wisneski wrote:

 I think I am doing what you suggest.  After changing the value of
 home the
 program does
  e.setHome( e.getHome().setStreet( new value));

 There was a typo in my code.  But even doing this, the update is
 not being
 written back to the database at commit or flush.


 On 9/10/06, Marc Prud'hommeaux (JIRA) [EMAIL PROTECTED] wrote:

 [ http://issues.apache.org/jira/browse/OPENJPA-43?page=all ]

 Marc Prud'hommeaux resolved OPENJPA-43.
 ---

Resolution: Invalid

 This is actually a known and intractible limitation: we are not
 able to
 intercept internal modifications for opaque types or arrays. So
 for those
 types, if OpenJPA is to detect that they were changed, they need
 to be
 re-set in their owning objects. E.g., in addition to doing:

 myPC.getSomeBlob().someInternalField++;

 you should also do:

 myPC.setSomeBlob(myPC.getSomeBlob());

 That should be sufficient to mary it dirty. Alternately, you can
 use the
 OpenJPAEntityManager.dirty() method to explicitly mark the field
 dirty.

  update of a persistent field using a @Lob annotation is not
 being marked
 dirty
 
  
-

 -
 
  Key: OPENJPA-43
  URL: http://issues.apache.org/jira/browse/
 OPENJPA-43
  Project: OpenJPA
   Issue Type: Bug
   Components: kernel
 Reporter: David Wisneski
 
  An entity has a persistent field which is a serialable class
 annotated
 with @Lob.  I am able to
  create and persist instances of this entity and field.  But when
 the
 entity is retrieved and the
  field is updated, the update is not written back at commit.
  @Entity
   class Employee {
@Id  int id;
@Lob  Address home;
  class Home implements Serializable {
  String street
EntityManager em =
em.getTransaction().begin();
Employee e = em.find(Employee.class, 1);
Address home = e.getHome();
home.setStreet(123 New Avenue);
e.setHome(e);
em.getTransaction().commit();   --  the update to home
 address does
 not occur.

 --
 This message is automatically generated by JIRA.
 -
 If you think it was sent incorrectly contact one of the
 administrators:
 http://issues.apache.org/jira/secure/Administrators.jspa
 -
 For more information on JIRA, see: http://www.atlassian.com/
 software/jira









Re: [jira] Resolved: (OPENJPA-43) update of a persistent field using a @Lob annotation is not being marked dirty

2006-09-14 Thread David Wisneski

I would think that this would have to be fixed in order to comply with JPA
spec.
The JPA spec section 3.2.3 says that updates to persistent entities are
written
back to the database during synchronization and 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.   There is not to my knowledge any requirement in JPA
that a
value has to be set null first.


On 9/14/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:



We might just be being too clever here ... if a field is set, but
oldvalue==newvalue, then we don't mark it dirty. That obviously
breaks down for cases like this, where we can't perform dirty
tracking on the opaque blob.

You might need to resign yourself to either having an intermediate
null setting, or else manually calling OpenJPAEntityManager.dirty()
on the field to make sure the system knows that it has changed. You
can always make your setter perform the additional intermediate null
setting.




On Sep 14, 2006, at 12:29 PM, David Wisneski wrote:

 that works.
Address a = e.getHome();
a.setCity(NewCity);
e.setHome(null);
e.setHome(a);

 Also if I create a new instance of Address as in
   Address newa = new Address();
e.setAddress(newa);

 Both of the above work.

 But doing an update with making a new copy of the Adresss does not
 work for
 me.
   e.setHome( e.getHome().setCity(NEW));

 Do I have to override equals on the Address ?


 On 9/14/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:

 David-

  There was a typo in my code.  But even doing this, the update is
  not being
  written back to the database at commit or flush.

 That's a little surprising.

 What happens if you do this:

 Blob home = e.getHome();
 home.setStreet(new value);
 e.setHome(null);
 e.setHome(home);




 On Sep 14, 2006, at 11:31 AM, David Wisneski wrote:

  I think I am doing what you suggest.  After changing the value of
  home the
  program does
   e.setHome( e.getHome().setStreet( new value));
 
  There was a typo in my code.  But even doing this, the update is
  not being
  written back to the database at commit or flush.
 
 
  On 9/10/06, Marc Prud'hommeaux (JIRA) [EMAIL PROTECTED] wrote:
 
  [ http://issues.apache.org/jira/browse/OPENJPA-43?page=all ]
 
  Marc Prud'hommeaux resolved OPENJPA-43.
  ---
 
 Resolution: Invalid
 
  This is actually a known and intractible limitation: we are not
  able to
  intercept internal modifications for opaque types or arrays. So
  for those
  types, if OpenJPA is to detect that they were changed, they need
  to be
  re-set in their owning objects. E.g., in addition to doing:
 
  myPC.getSomeBlob().someInternalField++;
 
  you should also do:
 
  myPC.setSomeBlob(myPC.getSomeBlob());
 
  That should be sufficient to mary it dirty. Alternately, you can
  use the
  OpenJPAEntityManager.dirty() method to explicitly mark the field
  dirty.
 
   update of a persistent field using a @Lob annotation is not
  being marked
  dirty
  
 
 -
  -
  
   Key: OPENJPA-43
   URL: http://issues.apache.org/jira/browse/
  OPENJPA-43
   Project: OpenJPA
Issue Type: Bug
Components: kernel
  Reporter: David Wisneski
  
   An entity has a persistent field which is a serialable class
  annotated
  with @Lob.  I am able to
   create and persist instances of this entity and field.  But when
  the
  entity is retrieved and the
   field is updated, the update is not written back at commit.
   @Entity
class Employee {
 @Id  int id;
 @Lob  Address home;
   class Home implements Serializable {
   String street
 EntityManager em =
 em.getTransaction().begin();
 Employee e = em.find(Employee.class, 1);
 Address home = e.getHome();
 home.setStreet(123 New Avenue);
 e.setHome(e);
 em.getTransaction().commit();   --  the update to home
  address does
  not occur.
 
  --
  This message is automatically generated by JIRA.
  -
  If you think it was sent incorrectly contact one of the
  administrators:
  http://issues.apache.org/jira/secure/Administrators.jspa
  -
  For more information on JIRA, see: http://www.atlassian.com/
  software/jira