在不破坏代码的情况下管理 Oracle 包的策略
我很好奇人们如何在应用程序中管理他们的包。
例如，在我们的开发实例中，应用程序开发人员可能想要更改存储过程。但是，更改存储过程将破坏现有的 Java 代码，直到更新 DAO 层以适应更改为止。
我的典型做法是将新的过程实现放入“DEV”包中。然后，开发人员可以更改对此包的引用，进行测试，然后当我们准备好时，我们可以替换“生产”包中的过程，将其从 DEV 中删除，然后开发人员将其引用更改回生产包。
然而，我发现它并不像我想要的那样顺利。首先，如果有一堆依赖于 DEV 包的 Java 代码，那么我就处于与直接编辑生产包相同的情况 - 如果我破坏了包，我就会破坏一堆代码。
其次，人们很忙，而我们没有时间尽快将软件包投入生产。然后，我们有两个版本的存储过程，很难记住哪些已投入生产，哪些尚未投入生产。
目标是让开发人员继续工作。是的，它是一个开发服务器，但我们不想意外地破坏代码。
谁能提出对他们有用的方法来解决这个问题？
I'm curious to find out how people manage their packages in their applications.
For example, in our development instance, an application developer may want a change to a stored procedure. However, changing the stored procedure will break the existing Java code until the DAO layer is updated to accommodate for the changes.
My typical practice has been to put the new procedure implementation into a "DEV" package. The developer can then change his reference to this package, do his testing and then when we're ready, we can replace the procedure in the "production" package, delete it from DEV and the developer changes his reference back to the production package.
However, I'm finding it doesn't work as swimmingly as I'd like. First, if there's a bunch of Java code which depends on the DEV package, then I'm in the same situation as if were editing the production package directly - if I break the package, I'll break a bunch of code.
Second, people get busy and we don't get around to moving the package into production as soon we should. Then we have two versions of the stored procedure floating around and it gets difficult to remember what has been moved into production and what hasn't.
The goal is to keep the developers working. Yes, it's a development server, but we don't want to be breaking code unexpectedly.
Can anyone suggest methodologies that have worked for them to address this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果每个开发人员在数据库中都有自己的模式，并且共享模式中的所有对象都有公共同义词，并且所有 Java 代码都使用非限定对象名称，则特定开发人员模式中的包的本地副本将优先于共享版本。因此，开发人员 A 可以获取该包的当前版本，将其安装在他或她的本地模式中，对包进行所需的任何更改，并在自己的开发环境中进行任何必要的 Java 更改（我假设开发人员有自己的本地应用程序服务器）。当两组更改都足够稳定以至于可以签入共享开发环境时，PL/SQL 包和 Java 更改都可以构建到共享开发环境（共享开发应用程序服务器和 PL/SQL 中的真实模式）。开发数据库）。然后，开发人员可以删除该包的本地副本。
只要开发人员从源代码控制中检查 PL/SQL 来开始更改，而不是假设他们架构中的任何本地副本都是最新的，这种方法就相当有效——如果开发人员保留旧的本地版本的代码在他们的本地模式中，他们最终可能会遇到难以调试的问题，因为他们的 PL/SQL 和 Java 版本不同步。您可以通过自动化流程来解决该问题，例如，如果在合理的时间内没有修改包，或者开发人员没有在源代码管理中检出这些包，或者通过构建脚本，则从开发人员模式中删除包作为构建过程的一部分，开发人员可以自动刷新其架构。
If each developer has their own schema in the database and there are public synonyms for all objects in the shared schema and all the Java code uses non-qualified object names, then a local copy of the package in a particular developer's schema will have precedence over the shared version. So developer A can take the current version of the package, install it in his or her local schema, make whatever changes are desired to the package, and make whatever Java changes are necessary all within their own development environment (I'm assuming that developers have their own local app server). When both sets of changes are sufficiently stable that they can be checked in to the shared development environment, both the PL/SQL package and the Java changes can be built out to the shared development environment (the shared development app server and the real schema in the development database). The developer can then drop their local copy of the package.
That approach works reasonably well so long as the developers are checking the PL/SQL out of source control to start their changes rather than assuming that whatever local copy they have in their schema is current-- if developers keep old, local versions of code around in their local schema, they may end up with difficult to debug issues where their PL/SQL and Java versions are out of sync. You can resolve that problem by automating processes that, for example, drop packages from developer schemas if they haven't been modified in a reasonable period of time and if those packages aren't checked out by the developer in source control or by building scripts that let a developer automate the refresh of their schema as part of the build process.
仅当过程规范发生变化（即参数的数量、名称等）时，Java/DAO 层才会受到影响。缓解策略是
对过程和函数使用包，以便可以重载它们
创建或替换 pkg 是
proc（varchar2 中的 p1）；
proc（varchar2 中的 p1，number 中的 p2）；
end;
通过重载，您可以在一个包中拥有多个同名的过程，只是参数的数量和/或数据类型不同。11gR2
引入了版本控制来解决这个问题。它允许包的多个版本，并且应用程序代码选择它想要查看的代码的“版本”（版本） - 默认的“基础”版本或开发版本。
但是我怀疑升级数据库版本并不是一个实际的解决方案。
The Java/DAO layer should only be affected if the procedure specification changes (ie number, name etc of parameters). Mitigation strategies for this are
Use packages for procedures and functions so you can overload them
create or replace pkg is
proc (p1 in varchar2);
proc (p1 in varchar2, p2 in number);
end;
With overloading you can have multiple procedures with the same name in a package just with different numbers and/or datatypes of the parameters
11gR2 has introduced Editioning to solve this problem. It allows multiple versions of packages and the application code choose which 'edition' (version) of the code it wants to see - the default 'base' edition or a development version.
However I suspect upgrading the database version isn't a practical solution.