Você gosta de repetir operações de rotina indefinidamente? Então eu não. Mas toda vez que no cliente SQL ao trabalhar com o armazenamento Rostelecom, tive que registrar manualmente todas as junções entre as tabelas. E isto apesar de em 90% dos casos os campos e condições de adesão às mesas coincidirem de pedido para pedido! Parece que qualquer cliente SQL possui funções de preenchimento automático, mas para armazenamentos nem sempre funciona: raramente incluem restrição única e chave estrangeira para melhorar o desempenho, e sem isso o programa não saberá como as entidades estão relacionadas a cada outro e o que ele pode fazer por você.
Depois de passar por negação, raiva, barganha, depressão e aproximação da aceitação, decidi - por que não tentar implementar o preenchimento automático com blackjack sozinho e fazê-lo da maneira certa? Eu uso o cliente dbeaver, escrito em java, ele tem uma versão comunitária de código aberto. Um plano simples amadureceu:
- Encontre classes no código-fonte responsáveis pelo preenchimento automático
- Redirecione-os para trabalhar com metadados externos e extraia informações sobre junções de lá
- ???
- LUCRO
Eu descobri o primeiro ponto rapidamente - encontrei uma solicitação no rastreador de bugs para ajustar o preenchimento automático e no relacionado descobriu a classe SQLCompletionAnalyzer. Olhei o código e é o que preciso. Resta reescrevê-lo para que tudo funcione. Esperei por uma noite livre e comecei a pensar na implementação. Decidi escrever regras de link de tabela (metadados) em json. Não tinha experiência prática de trabalho com este formato e a tarefa atual foi vista como uma oportunidade para corrigir esta omissão.
Para trabalhar com json resolvi usar a biblioteca do Google. Foi aqui que as surpresas começaram. Acontece que o dbeaver, como um verdadeiro aplicativo, foi escrito na plataforma Eclipse usando a estrutura OSGi. Para desenvolvedores experientes, isso torna conveniente o gerenciamento de dependências, mas para mim era mais como magia negra, para a qual eu claramente não estava pronto: como sempre, importo as classes que preciso da biblioteca json-simple no cabeçalho do a classe editada, especifique-a no pom.xml, após o que o projeto se recusa categoricamente a montar normalmente e trava com erros.
No final consegui corrigir os erros de build: registrei a biblioteca não no pom.xml, mas no manifesto manifest.mf, conforme exigido pelo OSGI, especificando-a como pacote de importação. Não é a solução mais bonita, mas funciona. Então apareceu a próxima surpresa. Se você estiver desenvolvendo no Intellij Idea, você não pode simplesmente começar a depurar seu projeto com base na plataforma Eclipse: um desenvolvedor inexperiente deve sofrer tanto quanto um analista sem a conclusão da consulta. Os próprios desenvolvedores do castor vieram em socorro, indicando no wiki todas as danças com pandeiro que precisam ser feitas. O mais chato é que mesmo depois de todos esses agachamentos, o projeto não queria ser lançado em depuração com a biblioteca json conectada via import-package (apesar de ainda ter sido montada com sucesso no produto final).
Naquela época, eu já havia percebido a inconveniência de usar json para minha tarefa - afinal, os metadados deveriam ser editados manualmente, e o formato xml é mais adequado para isso. O segundo argumento a favor do xml foi a presença de todas as classes necessárias no JDK, o que possibilitou deixar de brigar com uma biblioteca externa. Com muito prazer, transferi todos os metadados de json para xml e comecei a editar a lógica de preenchimento automático.
Exemplo de metadados
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tableRelations>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_partner</rightTable>
<joinColumnPair leftColumn="partner_key" rightColumn="partner_key"/>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
</tableRelation>
<tableRelation>
<leftTable>dim_account</leftTable>
<rightTable>dim_branch</rightTable>
<joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
<joinColumnPair leftColumn="branch_key" rightColumn="branch_key"/>
</tableRelation>
</tableRelations>Como resultado eu nas classes SQLUtils e SQLCompletionAnalyzer. A ideia é esta: se o programa não conseguir encontrar sugestões de preenchimento automático adequadas usando a lógica básica, ele verifica a presença de possíveis junções usando um arquivo xml externo. O próprio arquivo armazena pares de tabelas indicando os campos pelos quais essas tabelas precisam ser vinculadas. As restrições sobre as datas de validade técnica dos registros eff_dttm e exp_dttm e o sinalizador de exclusão lógica Deleted_ind são definidas por padrão.
Quando foram feitas alterações no código, surgiu a questão - quem preencherá o arquivo com metadados? Existem muitas entidades no repositório, é caro registrar você mesmo todas as conexões. Como resultado, decidi atribuir esta tarefa aos meus colegas analistas. Postei o arquivo de metadados no svn, de onde é feito um checkout para o diretório local com o programa. O princípio é este: apareceu uma nova entidade no repositório? Um analista insere possíveis junções no arquivo, confirma as alterações, os demais verificam por si mesmos e aproveitam o preenchimento automático de trabalho: comunidade, acúmulo de conhecimento e tudo mais. Realizei um workshop sobre como usar o programa para colegas, escrevi um artigo no Confluence - agora a empresa tem mais uma ferramenta conveniente.
Trabalhar nesse recurso me deu a compreensão de que não há necessidade de ter medo de mexer em projetos de código aberto - via de regra, eles possuem uma arquitetura clara, e até mesmo o conhecimento básico da linguagem será suficiente para experimentos. E com certa persistência, você poderá até se livrar das odiadas operações rotineiras, economizando tempo para novos experimentos.
Fonte: habr.com