updating where we have lazy loaded associations

BIZ TMS Aurelius
1
When a lazy loaded association is used the object manager always includes the foreign key in the update whether it has been changed or not.  Is this by design because it seems like a bug to me?  

 Example one - change the comment and don't lazy load the stage.

  FController.Find(LoadDetailID);
  //StageID := FController.LoadDetail.Stage.Id;
  FController.LoadDetail.Comments := cChangeByObjectComment;
  FController.Save;
  FController.Manager.Refresh(FController.LoadDetail);
  CheckEquals(FController.LoadDetail.Comments, cChangeByObjectComment);
  //CheckEquals(StageID, FController.LoadDetail.Stage.Id, 'Stage');

UPDATE LOAD_DETAILS SET 
  COMMENTS = :A_COMMENTS
WHERE ID = :p_1;

  A_COMMENTS = 'Changed By Object'
  P_1 = 19337

 Example two - change the comment and lazy load the stage.

  FController.Find(LoadDetailID);
  StageID := FController.LoadDetail.Stage.Id;// get the value from the lazy loaded stage
  FController.LoadDetail.Comments := cChangeByObjectComment;
  FController.Save;
  FController.Manager.Refresh(FController.LoadDetail);
  CheckEquals(FController.LoadDetail.Comments, cChangeByObjectComment);
  CheckEquals(StageID, FController.LoadDetail.Stage.Id, 'Stage');


UPDATE LOAD_DETAILS SET 
  COMMENTS = :A_COMMENTS, 
  STAGE_ID = :A_STAGE_ID
WHERE ID = :p_2;

  A_COMMENTS = 'Changed By Object'
  A_STAGE_ID = 4 
  P_2 = 19337

2

The point here is optimization. When the object is loaded, its state is saved. At that point, Aurelius doesn't know the stage id. When the proxy is loaded, the stage id is known, but the object state is not updated, first because other properties might have been changed at that point, second because it will slow down the process. 

But maybe it should be reviewed indeed.
3

The problem this is giving us is that we time-stamp every update on a table by a trigger and Aurelius is cascading updates on all the lazy loaded associated tables.  Why this matters to us is that we are developing a weighbridge application and whilst it's fine to say record a comment against a load once it has completed it's really not OK to have the time-stamp change on the associated tally roll table that has all the weights that have come directly from the weighbridge.  If our customers notice that TallyRoll.DateUpdated is later than TallyRoll.DateWeigh they will start to suspect either dishonesty from their employees or incompetence from us. So why don't we just remove the lazy loading?  Well there can be up to a million weighings in some of our customers databases and so we only want to join on tables when we absolutely have to.  In our completed load edit form we show the associated  weights using an Aurelius dataset with a field TallyRoll.Weighbridge.Description.  So when we update LoadDetail.Comment and then flush the object manager Aurelius is also updating the tally roll's weighbridge's ID.  


These are the little things that it takes time to understand when learning new technologies so I thought I would record it here for others as they might be having similar issues.  Again many thanks Wagner for your assistance in these matters, it makes a real difference when we as end users of a product can speak directly to the developers.
4

Steve, I consider this a bug and I think this should be fixed indeed. We will manage to get the proxy foreign key field to not be updated unless the value is effectively changed.

5

That is good news. I've experienced the same issue, and thinking it was "just the way things worked", I actually removed a lot of my lazy loaded lists and handled them manually.

6

This has been fixed. Any registered user interested in having this fix before we release an official version including it, please send us a direct e-mail to our support address to receive the patch.