I believe that overriding a rule is probably not a good idea and that is the reason we have the concept of ruleset version so that at anytime developers can refer back and check what was the design or content of a rule in earlier versions.
Also you may want to explore the option of rule set branching.
The behavior you suggest would be convenient. I'll acknowledge that.
However, I think this is a case in which convenient != good
RuleSet versioning and other programming constraints are often inconvenient by design. As Santanu Bhattacherjee notes, the suggested behavior contradicts a fundamental principle of RuleSet versioning and Check Out/Check In.
In a similar fashion, suppose my app is for scheduling jobs for house painters. Please forgive the sloppy SQL syntax below - this is meant to be a quick, fictional example.
- I have the table: PAINTING_JOBS (ID, DUE_DATE, PAINTER, COLOR)
- COLOR has the constraint IN ('White','Grey','Brown','Blue')
- I attempt
INSERT into PAINTING_JOBS(id.nextval, '30-Mar-2016','Bob the Painter','PINK');
It would be convenient if the DB would alter the constraint to add PINK to the color choices, but it would not be desirable behavior.
Disclaimer: my argument here will be undone if you ask my 4-year-old daughter her opinion, which would surely be that all houses would be painted pink, preferably with spots.