主页 / dba / 问题 / 157509
Accepted
durette
Asked: 2016-12-08 10:26:16 +0800 CST

如何在方法级别管理 PL/SQL 包源？

  • 772

在我们的 ERP 应用程序套件中，我们有非常少量的 PL/SQL 包，它们本质上是大型的、单一的，包含各种各样的功能。（这是因为每个包都需要在 ERP 套件本身中进行额外的配置。）将整个 API 置于源代码控制中是令人望而却步的，因为同时开发的项目可能会在管道中跳跃。现在，我们在方法级别手动部署到 QA 和 PROD，通过从文本文件中复制方法来修改方法并将其添加到包中。（我们使用 Allround Automations 的 PL/SQL Developer 与他们合作。）这既费时又容易出错，我想以 DevOps 的方式自动化这个过程。使用现有的实用程序，有没有办法将包方法作为离散文件存储在源代码管理中，并将它们单独部署到它们的包中？

oracle oracle-11g-r2

1 个回答

  1. Best Answer

    如果您实际上遇到了XY 问题，请考虑一下。是的。

    使用现有的实用程序，有没有办法将包方法作为离散文件存储在源代码管理中，并将它们单独部署到它们的包中？

    对我来说，这听起来是一个特殊的要求。在数据库中，PL/SQL 包是一个单独的原子单元（实际上有两个单元（一个规范和一个主体），但在这种情况下是不相关的）作为一个整体进行修改和部署。

    让我们改一下问题：

    使用现有的实用程序，有没有办法将 Java 类方法作为离散文件存储在源代码管理中，并将它们单独部署到它们的类中？

    我会说这很愚蠢。IMO 应该像对待任何其他编程语言源代码一样对待 Oracle PL/SQL 源代码。

    （我不知道有这样的工具，但你很可能可以自己制作。）

    你真正的问题是单一的 PL/SQL 包：

    [...] PL/SQL 包，它们本质上是大型的、单一的，包含各种各样的功能。

    这与您的并行开发路径相冲突。

    阅读精美手册：

    包是一个模式对象，它对逻辑上相关的 PL/SQL 类型、变量、常量、子程序、游标和异常进行分组。

    最后是根本原因：

    [...] 因为每个包都需要在 ERP 套件本身中进行额外配置。

    IMO尾巴摇狗。

    解决这个问题，将您的 PL/SQL 重构为具有模块化结构，您的开发/部署冲突问题将基本消失。

    我不知道“ERP 套件配置”的详细信息，但我肯定它的 PITA 因素比当前的混乱要小得多。

    • 1

相关问题