我很好奇人们如何在应用程序中管理他们的包。
例如，在我们的开发实例中，应用程序开发人员可能想要更改存储过程。但是，更改存储过程将破坏现有的 Java 代码，直到更新 DAO 层以适应更改为止。
我的典型做法是将新的过程实现放入“DEV”包中。然后，开发人员可以更改对此包的引用，进行测试，然后当我们准备好时，我们可以替换“生产”包中的过程，将其从 DEV 中删除，然后开发人员将其引用更改回生产包。
但是，我发现它并不像我希望的那样顺利。首先，如果有一堆依赖于 DEV 包的 Java 代码，那么我就处于与直接编辑生产包相同的情况 - 如果我破坏了包，我就会破坏一堆代码。
其次，人们很忙，我们没有时间尽快将包投入生产。然后，我们有两个版本的存储过程，很难记住哪些已移入生产环境，哪些尚未移入生产环境。
目标是让开发人员继续工作。是的，它是一个开发服务器，但我们不想意外地破坏代码。
有人可以提出对他们有用的方法来解决这个问题吗？
最佳答案
如果每个开发人员在数据库中都有自己的模式，并且共享模式中的所有对象都有公共(public)同义词，并且所有 Java 代码都使用非限定对象名称，则特定开发人员模式中的包的本地副本将优先于共享版本。因此，开发人员 A 可以获取该包的当前版本，将其安装在他或她的本地模式中，对包进行所需的任何更改，并在自己的开发环境中进行任何必要的 Java 更改(我假设开发人员有自己的本地应用程序服务器)。当两组更改都足够稳定以至于可以 checkin 共享开发环境时，PL/SQL 包和 Java 更改都可以构建到共享开发环境(共享开发应用程序服务器和 PL/SQL 中的真实模式)。开发数据库)。然后，开发人员可以删除该包的本地副本。
只要开发人员从源代码控制中检查 PL/SQL 来开始更改，而不是假设他们架构中的任何本地副本都是最新的，这种方法就相当有效——如果开发人员保留旧的本地版本由于 PL/SQL 和 Java 版本不同步，他们最终可能会遇到难以调试的问题。您可以通过自动化流程来解决该问题，例如，如果在合理的时间内没有修改包，或者开发人员没有在源代码管理中 check out 这些包，或者通过构建脚本，则从开发人员模式中删除包作为构建过程的一部分，开发人员可以自动刷新其架构。
关于oracle - 在不破坏代码的情况下管理 Oracle 包的策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1889734/