Hi Kieran,
That is an interesting thought. To mark the relationship as "Mandatory" but yet leave the foreign key itself as optional ("allows null"). You would think the two would need to back each other up though, and to a casual developer passing by and perusing your model he might think you were sloppy,
he might, but the customers and endusers appreciate the lack of "A System Error has Occurred" messages! The database NOT NULL is enforcing the foreign key presence so who cares.
or at least not be sure if the relationship should truly be "mandatory" or "optional".
Well, just tell the team mates about the situation and they will accept it ........ if not, then buy them a Guinness and try again to explain and I am sure they will be OK after that ;-)
I understand you are brainstorming here.
not really ... just a simple workaround to an annoying problem that manifests itself *sometimes* in the WO Frameworks and I am too busy to figure out the "why WO does that" part!
Thank you for that. But what led you down the path to this solution?
Deadlines .... "Necessity is the mother of invention" ..... aka "Deadlines are the mother of getting things done." :-)
Can you shed some light on why an object in the "deleted" bucket would get moved to the "updated" bucket during the various processing that happens when you call ec.saveChanges()... particularly suspect of "processRecentChanges()" ?
Not without spending time investigating ..... and no time for that while things need to get done....
What exactly is happening under the covers to make the "allows null" option work?
The nullified foreign key passes the validateForSave
Try it and let us know if it fixes your problem.