RE: looking for doc with diagrams on redo and undo for java developers (new title: Reuse of bad routines is worse than spaghetti code)
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <ryan_gaffuri@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 28 Sep 2004 13:54:26 -0400
To the barracades, my friends!
We must stamp out the notion that REUSE is a justification to populate the
world with bad code.
They want a reusable update handler? Fine. Write a good one and reuse it at
will. Better yet, have someone give you one that already works.
Guns don't kill people.
GO TOs don't create spaghetti code.
Object handling principals and packages don't justify reuse and propagation
of bad code.
Bad people can kill people a whole lot easier with guns than without guns.
Bad programmers can obscure all logical flow easier with GO TOs than with
structured languages.
Bad programmers have an easier time passing off lousy code in Object
Oriented languages by claiming re-usability.
Now, in your case, they either have a new value for a column for a value or
they don't. It is no big hairy deal to string together an enumeration
of columns with changed values: All they have to do is filter out the
unchanged columns. If they are already describing the table and generating
the update statement dynamically this should be child's play. If it is
bundled in a reusable routine it should *NOT* be a big deal to change it. If
it is *NOT* bundled, then they really, really missed the boat on object
orientation and reuse. Did I miss a case? Oh, okay, it is possible that they
are using a generator so that each object handler is principally identical
except for the actual table_name and column names, so that it is not
dynamic. For static generators that comes out on the order of the factorial
of the number of columns, so that could be a lot of code.
In that case it would become a measured case of dynamic prep time versus the
total waste for always updating everything. Except in the cases of DDL
excluded at run time environments where security resolution and name mapping
is guaranteed so true compilation can bybass dictionary queries (such as old
SQL/DS using EXEC PL/I and stuff like that) you would have to be updating
nearly every column nearly every time for the update all columns thingy to
win.
Sounds more to me they used mid 60's style replication of copy books style
of reuse. That practice was a great way to keep COBOL programmers busy and
let them reach bonuses for number of lines of debugged code generated.
Maybe I missed something big time here about how they are using the Object
method and yet this change is a major big deal. Please let me know if I did.
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of
ryan_gaffuri@xxxxxxxxxxx
Sent: Tuesday, September 28, 2004 11:37 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: looking for doc with diagrams on redo and undo for java
developers
Object Oriented programming is all about reuse so our java guys made a
universal update statement that updates all columns in a table, even
unchanged columns. I know its bad, but its a major re-write to change this.
I was digging through the otn docs and some books and everything that leads
me to this requires a significant amount of reading. Multiple chapters
etc...
anyone know a short article that explains undo and redo along with diagrams
and why its bad to update unchanged columns that is easy for a non-oracle
person to follow?
checked the concepts doc, but they would probably have to read 50-70 pages
to get the basic idea.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
