I'm curious why the orderedit class uses inconsistent methods for updating children. The DataPortal_Insert() method has this in relation to the child collection:
And the DataPortal_Update() method has this in relation to the child collection:
However, the OrderLineItems is not marked with RelationshipTypes.Child in it's property declaration so if I'm reading this right the DataPortal_Update() call to fieldmanager updatechildren will never cause orderlineitems to update.
The data access ebook seems to indicate (and if anyone can confirm this I'd appreciate it) that there's no effective difference in using either method other than when you directly call DataPortal.Updatechild you have control over the order that multiple child objects get updated.
So is this a typo or intentional or..?
This is errata (a bug). I've forwarded it to firstname.lastname@example.org so it is in the list of things to be fixed.
The properties should be marked with the Child enum value in any case.
I think the explicit child update in the one case is there because I needed to copy-paste some example code into the ebook, and forgot to undo the change in the code before commiting to svn...
Thank you for your help!
So your intent would have been to use FieldManager.Updatechildren and mark the property accordingly? As opposed to calling DataPortal.UpdateChild...etc.
Is there any difference between the two other than having control over the order of child updates if calling DataPortal.UpdateChild directly?
That is correct.
There is no difference. FieldManager.UpdateChildren just loops through all the child objects and calls DataPortal.UpdateChild on each one. You have no control over the order this occurs, and that is why you'd use the explicit option - to gain that control.
Hi Rocky, one thing that came to mind reading your responses:
Is there any reason to set the properties child enum value if we never update children via FieldManager.UpdateChildren?
Persistence and lazy loading are the two areas that use the value right now. But you never know what we might do in the future :)
Copyright (c) Marimer LLC