在不破坏代码的情况下管理Oracle包的策略

Question

我很想知道人们如何在他们的应用程序中管理他们的包。

例如，在我们的开发实例中，应用程序开发人员可能希望更改存储过程。但是，更改存储过程将破坏现有Java代码，直到更新DAO层以适应更改。

我的典型做法是将新程序实现放入“DEV”包中。然后开发人员可以更改他对此包的引用，进行测试，然后当我们准备好时，我们可以替换“生产”包中的过程，从DEV中删除它，开发人员将他的引用更改回生产包。

然而，我发现它并不像我想的那样游泳。首先，如果有一堆Java代码依赖于DEV包，那么我就像直接编辑生产包一样 - 如果我破坏了包，我将打破一堆代码。

其次，人们忙碌，我们不应该尽快将包裹投入生产。然后我们有两个版本的存储过程浮动，很难记住已经转移到生产中的东西和没有的东西。

目标是让开发人员继续工作。是的，它是一个开发服务器，但我们不希望意外地破坏代码。

有人可以提出有效的方法来解决这个问题吗？

Answer 1

如果每个开发人员在数据库中都有自己的架构，并且共享架构中的所有对象都有公共同义词，并且所有Java代码都使用非限定对象名称，那么特定开发人员架构中的包的本地副本将优先于共享版本。因此，开发人员A可以获取包的当前版本，将其安装在他或她的本地模式中，对包进行任何需要的更改，并在他们自己的开发环境中进行所有必要的Java更改（我假设开发人员）拥有自己的本地应用服务器）。当两组更改足够稳定以便可以检入共享开发环境时，PL / SQL包和Java更改都可以构建到共享开发环境（共享开发应用程序服务器和实际模式中）开发数据库）。然后，开发人员可以删除其本地副本。

只要开发人员检查源控制中的PL / SQL以启动他们的更改而不是假设他们的架构中的任何本地副本是最新的 - 如果开发人员保留旧的本地版本，那么这种方法工作得相当好在他们的本地模式中的代码，他们可能最终难以调试PL / SQL和Java版本不同步的问题。您可以通过自动化流程来解决该问题，例如，如果未在合理的时间段内修改了开发人员模式中的包，并且开发人员未在源代码管理中或通过构建脚本检出这些包这让开发人员在构建过程中自动刷新他们的模式。

Answer 2

只有在过程规范发生变化（即参数的编号，名称等）时，才会影响Java / DAO层。缓解策略是

1. 使用参数的DEFAULT值添加新参数，以便不需要传递它们。
2. 如果参数的位置被称为[例如pkg.proc_a（1,2,3）]，请不要更改参数的顺序，如果按名称调用则重命名参数[例如pkg.proc_b（p_1 =＆gt; 1，p_2） =＆gt; 2）]

3. 使用程序包和函数包来重载它们

   创建或替换pkg是   proc（varchar2中的p1）;   proc（varchar2中的p1，数量中的p2）; 端;

通过重载，您可以在包中使用相同名称的多个过程，只是具有不同的参数数字和/或数据类型

11gR2引入了Editioning来解决这个问题。它允许多个版本的软件包和应用程序代码选择它想要看到的代码的“版本”（版本） - 默认的“基础”版本或开发版本。

但我怀疑升级数据库版本不是一个实用的解决方案。