• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 213
  • Last Modified:

V URGENT! Object updated in mapper but not in calling code!

I am having trouble with a bug that has popped up in our Object Mapper. If I pass in (to the mapper) an object to be destroyed, during the destruction process, the object is removed from any collections that form part of any bi-directional object relationship that the object is involved in. In the mapper this works fine, but the changes to the collection are not reflected outside of the mapper. Take the following scenario:

I have an object called objDeliveryCategory, which has a collection called allDeliveryBands, which contains 3 DeliveryBand objects. Each of these DeliveryBand objects also has an inverse relationship back to objDeliveryCategory, thus making a bi-directional 1..* relationship.  When I pass in one of the DeliveryBand objects to be destroyed: ObjectMapper.destroyObject(objDeliveryBand), the mapper removes objDeliveryBand from the allDeliveryBands collection that makes up part of the relationship and persists the changes to the collection. This all works fine and the correct rows are removed from the database. When I debug-step through the code in the mapper and use the command window to check the collection after the object has been removed and the collection persisted, I get the following:

?objPInverse.count
2 {Integer}
[Integer]: 2 {Integer}
?objPInverse.oid.ToString() 'Check the oid of the object to ensure it is the same collection
"e94c68fa-e0e9-4816-88af-05190dd74e00"

This is fine as the collection now has just 2 objects. However, once the ObjectMapper.destroyObject(objDeliveryBand) bit is completed, if I continue to step through the code of the subroutine that called the destroyObject function and check the collection that should now be minus one object, I get the following:

?Me.myDeliveryCategory.allDeliveryBands.Count()
3
?Me.myDeliveryCategory.allDeliveryBands.oid.ToString()
"e94c68fa-e0e9-4816-88af-05190dd74e00" 'The oid of the object is the same, so this is the same collection

And the object is still there. The database had been successfuly updated, the mapper seemed to be doing its job, but once out of the mapper, the object hasn't been removed. What is going on? The only thing that I can think of is that the offending collection is somehow being copied within the mapper. Could it be something else? And if not, how could this kind of behaviour happen?

This is an URGENT problem as it is holding up a project with an impending deadline. I've assigned 500 points, but am happy to add more. Any help is greatly appreciated.

Regards.

Stephen.
0
sroughley
Asked:
sroughley
  • 2
1 Solution
 
Bob LearnedCommented:
Did you find a solution to this yourself?

Bob
0
 
sroughleyAuthor Commented:
Ah. I completely forgot about asking this question. Yes, it was solved. It turned out that the interface was caching the objects in the Session StateBag, which removed them from the control of the DAL's IDMap/Cache.
0
 
Bob LearnedCommented:
Could you clean up this question then?

Thanks,
Bob "Cleanup Volunteer"
0
 
Computer101Commented:
PAQed, with points refunded (500)

Computer101
E-E Admin
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now