RE: looking for doc with diagrams on redo and undo for java developers (new title: Reuse of bad routines is worse than spaghetti code)

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of ryan_gaffuri_at_comcast.net
Sent: Tuesday, September 28, 2004 11:37 AM To: oracle-l_at_freelists.org
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.

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Tue Sep 28 2004 - 12:51:52 CDT