Prev: Multiple selects in one
Next: Oracle 10g on Solaris 10 non-global zones with asynchronous I/O
From: Galen Boyer on 11 Mar 2010 20:58
"jeffchirco(a)gmail.com" <jeffchirco(a)gmail.com> writes:

> 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.

If you do this then you need to treat your codebase just as though you
have multiple versions of an application in production at different
client sites.

You need a different schema for each "version" of your production copies
and each schema needs to own all of the code from the Source Control
which represents this version. You will need private synonyms from your
mainline ddl and appropriate privileges granted to each schema.

Branch-1 is in production (ie, the procedures too risky to change right
now). The clients of this codebase on Branch-1 and they log into schema-1.

Branch-2 is from the same trunk of the source control. You create
schema-2. Compile the code there. Point the clients that are ready to
move to the new codebase there.

Basically, it can be done, but, if the reasoning is because of what it
sounds like, which is you have no regression testing, then, you do not
have the skillsets in house to do what I'm telling you will need to do
either.

But, renaming the procedures and copying code? Bad, bad news!!!!

--
Galen Boyer

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Shakespeare on 12 Mar 2010 04:12
Op 11-3-2010 6:17, Mladen Gogala schreef:
> On Wed, 10 Mar 2010 21:07:50 -0800, jeffchirco(a)gmail.com wrote:
>
>> 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.
>
> 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.
>
>
>

And I thought SourceSafe was a versioning system....
Versioning systems won't help if both versions of the procedure must be
kept in the software, indeed because other programs may need the old
version when they can not handle changes made to the original procedure.
I agree that versioning within the code is not the best way, but
sometimes it can not be avoided. But the new procedure should not be
considered a new version, but a complete new procedure, and like Álvaro
states, be given a new name. If both procedures share a lot of code, the
duplicate part should be taken out and be programmed as a separate
procedure and be called by both procedures.

Shakespeare
From: Jeremy on 12 Mar 2010 07:17
In article <pan.2010.03.11.16.16.48(a)email.here.invalid>,
no(a)email.here.invalid says...

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

What *is* the recommended method? I would probably do
"select count(pk_id_column)..."



--
jeremy
From: scottgamble on 12 Mar 2010 08:01
In a previous life I was in a situation where something similar had
been done.

There were 2 ids for each application. The ids had private synonyms to
a version of the
stored procs.

When functionality of the procedure was changing a new version went
through all the test cycles etc and was put in with a new version
number. (No change to the application yet).

The id that the application currently was not using had its private
synonyms updated to the new version of the stored proc.

One application server was changed to use the new id and thus the new
stored procedure.
If there were no issues with that app server the next day all the app
servers were changed to use the new id. The old id was then updated in
a day or so. I do not remember how the functionality change was
handled within the application itself.

Was a lot of manual work but it did work fairly well for rolling out
new versions and not forcing all apps using the procedure to change.
They could stay happily using the old version until they were ready to
change.




On Mar 10, 11:07 pm, "jeffchi...(a)gmail.com" <jeffchi...(a)gmail.com>
wrote:
> 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.

From: jeffchirco on 12 Mar 2010 10:47
Thanks for all your feedback. When I was talking about my developers
I was talking about the .Net developers, so I am being overruled by my
boss and the .Net team. I am the loan DBA here and I do most of all
the pl/sql development. The private synonyms option may work for
certain situations and I'll look into that. Unfortunately we don't
really have a change control system but I am going to start working on
one. Another problem is that we write all our own applications so we
have numerous applications out there and a lot of the users login with
their own oracle account.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Multiple selects in one
Next: Oracle 10g on Solaris 10 non-global zones with asynchronous I/O