New Procedurs With Version# In Name

#11

"jeffchirco (AT) gmail (DOT) com" <jeffchirco (AT) gmail (DOT) com> writes:

Quote:

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 (AT) netfront (DOT) net ---

#12

Op 11-3-2010 6:17, Mladen Gogala schreef:

Quote:

On Wed, 10 Mar 2010 21:07:50 -0800, jeffchirco (AT) gmail (DOT) 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

#13

In article <pan.2010.03.11.16.16.48 (AT) email (DOT) here.invalid>,
no (AT) email (DOT) here.invalid says...

Quote:

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

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

--
jeremy

#14

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... (AT) gmail (DOT) com" <jeffchi... (AT) gmail (DOT) com>
wrote:

Quote:

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.

#15

Shakespeare <whatsin (AT) xs4all (DOT) nl> writes:

Quote:

Op 11-3-2010 6:17, Mladen Gogala schreef:
On Wed, 10 Mar 2010 21:07:50 -0800, jeffchirco (AT) gmail (DOT) 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

How is this so? This screams multiple branches of the codebase which is
exactly why versioning control is so needed to accomplish this.

Quote:

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

I disagree. Multiple schemas allow the same named objects. Make the
schema name have the branch name and this would work. The issue is that
there is a shared schema of tables. What do you do when the same named
table has a different structure for the different branches? Hm...
Adding new columns is now a subtype table. Removal of columns is a view
that hides the column. Changing names of columns is views.

Quote:

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.

Well, this is exactly what they seemingly are scared to do. Touch the
code.

--
Galen Boyer

--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

New Procedurs With Version# In Name

comp.databases.oracle.server comp.databases.oracle.server

Re: New Procedurs With Version# In Name - 03-11-2010 , 07:58 PM

Re: New Procedurs With Version# In Name - 03-12-2010 , 03:12 AM

Re: New Procedurs With Version# In Name - 03-12-2010 , 06:17 AM

Re: New Procedurs With Version# In Name - 03-12-2010 , 07:01 AM

Re: New Procedurs With Version# In Name - 03-12-2010 , 07:15 PM