Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

User Journal

Chacham's Journal: Mini rant: Stupid code (2)

Journal by Chacham

More on the stupid code:

Some_Func, which is called at the end, INSERTs the new batch number to the log TABLE and includes an EXCEPTION block catching DUP_VAL_ON_INDEX and OTHERS.

IOW, this PROCEDURE makes a best guess at what the batch number will be, writes it to a bunch of files, and only then attempts to put it into the log. If putting it into the log encounters any errors, it logs that and exits without any record in the log of the job! The job currently takes about an hour or two to run. Seriously, what were they thinking?

The current situation can be remedied via a SEQUENCE. As long as noone breaks the rule that all ids be popped off it (which can be enforced by removing rights to the TABLE and forcing all writes to go through a stored PROCEDURE) everything will be fine until the SEQUENCE runs out of numbers.

Of course, this entire approach is just plain wrong. The correct way to log a run with a generated number which is used in the output, is to start by logging first. This garantees the number is recorded and lets others job easily use a further number. This is basic stuff.

To use a SEQUENCE (or even the MAX() hack), INSERT the number, and find out what it is, just use the RETURNING clause:


This discussion has been archived. No new comments can be posted.

Mini rant: Stupid code (2)

Comments Filter:

You can be replaced by this computer.