If you can set enforcement for a rule, you can set up lack of enforcement

One of the things you can do with an internal tool I've been calling Program Q is run a program any time somebody wants to add or modify a record. The program has wide latitude in what it can do. It can inspect the record being added/modified, maybe record side information in another table, and one of the things it can decide to do is to reject the operation.

We have set up a validator in our main table to ensure that the widget being added or modified is priced within the approver's limit. But sometimes, there is an urgent widget request and we want to be able to bypass the validation temporarily. Is there a way to disable the validator just for a specific record, or to disable it for all records temporarily?

If you can set up a program to validate a record, you can also set up a program to not validate a record.

Suppose your current validator for adding a widget goes like this:

if (record.approver.limit < record.price) {
 record.Reject("Price exceeds approver's limit");
... other tests go here ...

And say you want to be able to allow emergency requests to go through even though, say, all approvers are unavailable. Because, maybe, the widget is on fire.

You could decide that a widget whose description begins with the word EMERGENCY is exempt from all validation, but it generates email to a special mailing list.

if (record.description.beginsWith("EMERGENCY"))
 // emergency override: send email
 // and bypass the rest of validation
if (record.approver.limit < record.price) {
 record.Reject("Price exceeds approver's limit");
... other tests go here ...

Of course, the EMERGENCY rule was completely arbitrary. You can come up with whatever rules you like. The point is: If you wrote the rules, you can also write the rules so that they have exceptions.

Comments (9)
  1. Kevin says:

    Just make sure the rules you come up with are not so complex as to require a "quick guide to EBNF" a la sudoers(5).


  2. Boris says:

    Hmm… There wasn't by any chance a startup overhead to running the program in question, which would've remained the same even if the validation rule = don't validate? It could've been the reason they wanted to remove the validation in the first place.

    [Seeing as they were running the program for every record modification, it's presumably fast enough not to be an issue. -Raymond]
  3. DebugErr says:

    And then, everyone begins abusing it by starting all their record descriptions with "EMERGENCY".

  4. Anon says:

    @DebugErr: There's nothing physically stopping you from pressing the fire alarm button at your office.  If you see smoke, pressing it is fine and you will be praised for it.  However, if you repeatedly press it without good reason, that will be career-limiting.

    An emergency change process could be dealt with by management in the same way – using it for genuine emergencies is fine and you will be praised for it; abusing it for non-emergencies should have consequences.

    Even if management won't take it seriously, it's possible to have more technical limits on an EMERGENCY process – e.g. if you abuse it then your access to the EMERGENCY process is revoked:

    > if (record.description.beginsWith("EMERGENCY") and record.author != 'DebugErr')

  5. Kevin says:

    @Anon: You're being rather optimistic.  Eventually, nothing is special any more.


    [The difference between this case and the one you cited is that this case involves human beings (the notification mailing list). Human beings are capable of detecting misuse. APIs aren't. -Raymond]
  6. cheong00 says:

    @Anon: Or email sent by abusers will go automatically to junk folder. No program modification needed. :)

    [In practice, when you use the EMERGENCY override, you (or your manager) will have to explain to the database administrators the nature of your emergency. -Raymond]
  7. cheong00 says:

    [In practice, when you use the EMERGENCY override, you (or your manager) will have to explain to the database administrators the nature of your emergency. -Raymond]

    Emmm… I thought it's sent to some senior management above according to approval path settings, instead of database administrators.

    There will also be reason and a link of approval page provided.

    Virtually all Accounting (for adjust of past months data) / HR (for leave and OT approval) / Purchasing Dept. applications I worked for have this kind of settings.

    In fact, for a lot of systems, DBA is not allowed to modify production data directly (except when running schema upgrade script for system updates). I don't think sending them request could help. :P

    [By "database administrator" I didn't mean "the IT people who keep the server running"; I meant "The people who set up the database and care about what goes into it." Maybe I should've used a different term. -Raymond]
  8. not an anon says:


    This is why I find the term DBA to be ambiguous.  First, you have the database operator who keeps the server running, applies patches, makes sure there's enough disk for everybody's databases, and babysits the DBMS if/when it decides to wet the bed at 2AM.  Then there's the database developer, who writes and tunes schemas and application queries, perhaps assisting with reporting as well depending on the database in question, and works with the database operator to troubleshoot failures.  Finally, there's what I'll call a "data custodian" — someone, usually from the business side, who has responsibility for making sure that the data in the database is satisfactory from a business standpoint.

  9. Kevin says:

    @Raymond: At my workplace, filing critical-severity change requests is considered part of a normal workflow which is used multiple times per week.  This is generally not the result of a bug or anything like that; it is "I want to roll my code out by Thursday"-type requests.

    Maybe I'm just too cynical.

    [Or maybe the people who set up the emergency override don't consider this to be an abuse of the system? (I.e., they were intentionally creating a backdoor so people can deploy faster with minimal oversight.) -Raymond]

Comments are closed.

Skip to main content