So when my developers need to make a change to a procedure, instead of
just recompiling the procedure they want to create a new procedure
named like sp_procedure2 and then use the new procedure in their
application.
They want to do this so that they don't mess up any other application
that might be calling the same procedure. And then when they can get
around to updating the other applications they will use the new
procedure. I was wondering if anybody else does this and what you
guys think. I am against it but I am getting overruled. My database
will look confusing, source safe will be confusing, and now I have to
maintain multiple procedures when something needs to change.

On Wed, 10 Mar 2010 21:07:50 -0800, jeffchirco (AT) gmail (DOT) com wrote:

Have your developers ever heard of something called "versioning system"?
There are several of those which are widely used. The names you will most
frequently encounter are git, svn and CVS. Those things can really help
with versions, branches and revisions. There are also commercial products
which do the same thing, but with a better GUI. Personally, I think that
GUI is for wimps, especially when it comes to versioning systems. One
should learn the CVS syntax by heart and know how to diff, how to see the
revision log, check in a new version, merge 2 branches etc.



--
http://mgogala.byethost5.com

jeffchirco (AT) gmail (DOT) com wrote:
This whole idea is odd because it assumes the tables themselves will
never change... I wholeheartedly agree that CVS would be better, but
another alternative would be to create a new schema, create private
synonyms for all the tables and let your developers knock themselves out
with their creativity in their own padded cell....

David Rolfe
Orinda Software
Dublin, Ireland

Orinda Software make "OrindaBuild", a Java Web Service Generator for Oracle.

El 11/03/2010 6:17, Mladen Gogala escribió/wrote:
Version control cannot really help in the problem he described: I don't
think they want to push changes to the live server and then revert those
changes one month later when they learn they broke some third-party out
there. (Of course, version control is a basic tool for development anyway.)

As for the OP, I see two possibilities:

1. The procedure is modified in order to fix a bug or make an optimization
2. The procedure is modified to alter its functionality

In the first case, the appropriate tool is unit testing. The procedure
should have a bunch of test cases so they can detect if a change of
enhanment breaks backward compatibility.

In the second case, it should be carefully considered if it's possible
to add new functionality while keeping backwards compatibility. If it's
not possible, it's likely that the procedure should not replace the old
one; but it should not have a name like sp_customer_list_v2 but
something on the line of sp_customer_list_for_mailing.


--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

On Mar 11, 8:07*am, "jeffchi... (AT) gmail (DOT) com" <jeffchi... (AT) gmail (DOT) com>
wrote:
[Tongue-in-cheek mode on] Switch to 11gR2 and use Edition-based
Redefinition (http://download.oracle.com/docs/cd/E...01/appdev.112/
e10471/adfns_editions.htm). Really powerful feature if used properly
as it allows your application code to evolve without breaking anything
(at least as described.) Hopefully, there are no serious defects in
initial implementation.

Now, seriously, it's nice that your developers care not to break
existing stuff, but this is one of the worst ways to evolve code I've
seen. Packages are there for implementation changes that do not affect
interfaces. They also support overloading, so if you need to change an
interface (add or remove an argument, change argument type, etc.) you
can add overloaded procedure to the package and Oracle will
automagically use the right version. And then there's testing. On a
test instance. With data set as close to production as possible.

Besides, aren't your developers aware of the scope of the changes they
introduce and possible side effects? What makes them think these
changes may break something? They should not happily clone interfaces
on every occasion just because they can and think it's safer - they
should do it only when unavoidable.

Mi dos centavos.

Regards,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com

On Mar 11, 12:07*am, "jeffchi... (AT) gmail (DOT) com" <jeffchi... (AT) gmail (DOT) com>
wrote:
Jeff, I will join with the other posters who have made several fine
suggestions and suggest you tell your developers that what they want
is not the way code changes should be managed.

You need a combination of source code control and change control
procedures in place that control the process by which code is marked
for update, changed, tested, and promoted. A paper trail showing that
these procedures are followed must be maintained.

You should also have an emergency change procedure documented.

HTH -- Mark D Powell --

On Thu, 11 Mar 2010 07:13:34 -0800, Mark D Powell wrote:

There is a sad situation if that is being instituted by the DBA. These
things are usually signed off by the CIO and carved into stone tablets
for later reuse. The commandments should read like this:

Nothing shalt be promoted to the group schema unless it has been
committed to the version system.

Thou shalt put meaningful comments into your code.

Thou shalt not use "select count(*)" to establish existence.

There are many, many more. Modern stone tablets can take much more than
10 commandments.

DBA is not the person with enough authority to introduce the development
process to the company. Management has to do that.



--
http://mgogala.byethost5.com

On Mar 11, 12:07*am, "jeffchi... (AT) gmail (DOT) com" <jeffchi... (AT) gmail (DOT) com>
wrote:

snip

Getting overruled by who exactly?

Is there any kind of change control team in your company?

On Mar 10, 9:07*pm, "jeffchi... (AT) gmail (DOT) com" <jeffchi... (AT) gmail (DOT) com>
wrote:
Even Oracle can't get this right. The first two off the top of my
head, statistics generation and job control.

It does make sense for major functionality changes, though Vladimir's
point about overloading is significant for more modern versions of
Oracle, for well-designed systems. (Did I just negate that for the
majority of systems?)

I agree with the chorus for version control. I've been in large and
small shops, and this is the reason for an integration database, in
addition to production and QA and developers own. Even in small shops
with a simple informal system, miscommunication inevitably screws
things up.

The Death part of the System Design Life Cycle is often overlooked. I
also have a lot of code where people didn't want to change procedures
to the new way, so old and new ways are kept, sometimes through
several generations of major ERP upgrades, sometimes with the upgrades
adding the same or conflicting capabilities as older bespoke code.
The real fun begins when they buy a new module that expects the new
code, with expectations it will just plug in because we are at that
version.

jg
--
@home.com is bogus.
Those darn "overpaid, overpriced IT people"!
http://www.signonsandiego.com/news/2...es-gets-tepid/

On Thu, 11 Mar 2010 08:44:33 -0800, John Hurley wrote:

There probably is a PHB in his company.



--
http://mgogala.byethost5.com