So, Stacey and I where chasing down this bug where when you added a PackageItem to a SourceCode's Package, only the first got added. Well... Until someone came back to the page and found that they had been added, they just never showed up in the list. It reaked of disconnected data caching issues.
Turns out, the issue was adding a PackageItem object that points to a Supplement Object that did not exist in the container. Once the SourceCode.GetSupplements() method was called it (correctly) set the ChildLoaded for Supplements to true, so subsequent calls to the Method would never check the DB for the underlying Supplement Object, and wouldn't hit the db to find it (since ChildLoaded was set to true for supplements), but it would add the PackageItem object since that only needed the key. In other words,
#1 SourceCode.GetPackageItems(); #2 SourceCode.AddPackageItem(key); #3 SourceCode.GetPackageItems();
#3 DID NOT end up returning the PackageItem added on #2.
In PackageItemController.Add load the Child object into the container.
We need to do this EVERYWHERE we have many to many relationships for effective use of Caching datasets. It's simple, but very easy to overlook (and probably is in many cases), and makes for tough debugging when not done.
Doing things like this in the back end (where they belong) really helps make the UI simple, and also makes the API much easier to use.
In short... if you see BusinessController.SelectWithFilters(xxx,true)....
9 out of 10 times, you're covering a problem that might be worth spending 10 minutes to investigate.
Begin Code snippet
// Get the Supplement object into the container SupplementController.Supplement(supplementKey, this.BusinessContainer); // old stuff PackageItem item = (PackageItem)NewRow(); item.InitializeNew(objectKey, parentKey, supplementKey); Rows.Add(item);
end code snippet