If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > How to manage legacy upgrades?

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 09-04-08, 11:37
Guy Harel Guy Harel is offline
Registered User
 
Join Date: Sep 2008
Posts: 1
How to manage legacy upgrades?

We have legacy Oracle procedures and functions in our customers db, in what we call our "infrastructure". These objects are used by several of our applications, but we cannot upgrade all our applications at the same because its too lengthly and complicated.

For example, we have the procedure JOURNALIZE. Our new version of Appl_1 need the new version of JOURNALIZE wich now use the new package P1. But the other applications cannot use the new JOURNALIZE, even if the interface is the same, because P1 needs to be initialized by the application.

So we decided to provice JOURNALIZE, with the same number of arguments, but which will dispatch the processing to JOUNALIZE_OLD, or JOURNALIZE_NEW, depending if P1 has is present, or has been initialized.

But then we realize we need to do that to a bunch of other procs and funcs.

Is there some king of approach, or design pattern, we can use to keep our legacy objects have the same interface, but provide different behavior depenping on who is calling.

Any ideas are welcome.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On