Início / dba / Perguntas / 157509
Accepted
durette
Asked: 2016-12-08 10:26:16 +0800 CST

Como posso gerenciar a origem do pacote PL/SQL no nível do método?

  • 772

Em nosso conjunto de aplicativos ERP, temos um número muito pequeno de pacotes PL/SQL que são grandes e monolíticos por natureza, contendo uma ampla variedade de funcionalidades. (Isso ocorre porque cada pacote requer configuração adicional no próprio pacote de ERP.) Colocar toda uma API no controle de origem é proibitivo porque projetos de desenvolvimento simultâneos podem saltar ao longo do pipeline. No momento, implementamos manualmente para QA e PROD no nível do método, modificando e adicionando métodos ao pacote copiando-os de arquivos de texto. (Trabalhamos com eles usando o PL/SQL Developer da Allround Automations.) Isso é demorado e sujeito a erros, e eu gostaria de automatizar esse processo no estilo DevOps. Usando um utilitário existente, existe uma maneira de armazenar métodos de pacote como arquivos discretos no controle de origem e implantá-los em seus pacotes individualmente?

oracle oracle-11g-r2

1 respostas

  1. Best Answer

    Alguns ponderam se você está de fato tendo um problema XY . YMMV .

    Usando um utilitário existente, existe uma maneira de armazenar métodos de pacote como arquivos discretos no controle de origem e implantá-los em seus pacotes individualmente?

    Para mim, isso soa como uma exigência peculiar. No banco de dados, um pacote PL/SQL é uma única unidade atômica (na verdade, existem duas unidades (uma especificação e um corpo), mas isso é irrelevante neste contexto) que é modificada e implantada como um todo.

    Vamos reformular a pergunta:

    Usando um utilitário existente, existe uma maneira de armazenar métodos de classe Java como arquivos discretos no controle de origem e implantá-los em sua classe individualmente?

    Eu diria que isso é simplesmente bobo. IMO deve-se tratar o código-fonte Oracle PL/SQL com o mesmo amor que qualquer outro código-fonte de linguagem de programação.

    (Não conheço essa ferramenta, mas você provavelmente pode fazer isso sozinho.)

    Seu problema real são pacotes PL/SQL monolíticos:

    [...] PL/SQL que são grandes e monolíticos por natureza, contendo uma ampla variedade de funcionalidades.

    Isso entra em conflito com seus caminhos paralelos de desenvolvimento.

    Lendo o bom manual :

    Um pacote é um objeto de esquema que agrupa tipos PL/SQL logicamente relacionados, variáveis, constantes, subprogramas, cursores e exceções.

    E finalmente a causa raiz:

    [...] porque cada pacote requer configuração adicional no próprio pacote ERP.

    IMO rabo abanando o cachorro.

    Resolva esse problema, refatore seu PL/SQL para ter uma estrutura modular e seus problemas de conflito de desenvolvimento/implantação praticamente desaparecem.

    Não conheço os detalhes da "configuração do pacote ERP", mas tenho certeza de que o fator PITA é muito menor do que a bagunça atual.

    • 1

relate perguntas