[firebase-br] controle de Versao de SPs / Views / Triggers

[Gladiston Santana]

Alterações de SPs que chamam outras SPs é um problema por causa das
dependências, elas devem vir numa ordem que nem sempre é possível, assim,
eu recomendo que você tenha as SPs que serão modificadas ou dependentes
apenas com o cabeçalho e no final um possível suspend se retornar algo.
Depois de rodar as SPs vazias então você vem com as que tem seu conteúdo
real.
Eu faço assim com uma leve modificação, como eu uso um programa feito por
mim, então eu faço meu programa pegar o script de todas as SP e executar
removendo o seu conteúdo, então inicialmente todas ficam vazias lá na
produção, depois rodo novamente todos script de SP só que dessa vez com
conteúdo real. Esse método não é novo, era a mesma coisa que já fazia com o
MSSQL.

Em qui., 24 de out. de 2024 às 13:43, Anderson Barretta via lista <
lista em firebase.com.br> escreveu:

> Olá pessoal,
> deixa eu expor uma dificuldade que temos aqui na empresa.
> hoje temos o nosso ERP usando uma banco FB nos clientes.
> então, aqui na empresa, temos o nosso banco de dados de desenvolvimento,
> centralizado, com a ultima versão do metadata.
> quando um desenvolvedor precisa fazer uma alteração no matadata, ele
> acessa esse banco interno, e faz a mudança, gerando um log de script que
> vai ser incluído junto na nossa próxima atualização, na mesma ordem que
> foi gerado. (parecido com o artigo do Cantú).
>
> isso funciona relativamente bem a muitos anos,
> mas quando existe uma concorrência de desenvolvedores precisando alterar
> a mesma SPs(Views,triggers,etc) com objetivos diferentes, complica um
> pouco.
> pq as vezes, um deles inicia a alteração, gerando o log, mas essa
> mudança não pode entrar na próxima atualização, pois a alteração depende
> de mais alterações em outros objetos e ainda não esta totalmente pronta.
> então o segundo ao iniciar a um ajuste simples, na mesma SP, acaba
> pegando essa SP já "alterada". então o log dele acaba incluindo tb as
> mudanças do primeiro desenvolvedor. hoje acabamos tratando isso de forma
> manual.
> mas penso que essa forma não seria muito sustentável com times maiores.
> então fica minha dúvida, como os colegas tratam esse controle de versão
> do Banco de desenvolvimento?
>
> jah pensei em exportar cada objeto em um arquivo separado. e controla
> pelo .svn mas não cheguei a um logística funcional e segura.
> enfim, desculpa o textão, mas qualquer sugestão é bem vinda.
>
>
>