Você gosta de repetir operações de rotina de tempos em tempos? Aqui estou eu. Mas sempre que o cliente SQL trabalhava com o repositório Rostelecom, eu precisava registrar todas as junções entre os identificadores das tabelas. E isso apesar do fato de que em 90% dos casos os campos e condições para a junção de tabelas coincidiram de consulta para consulta! Parece que qualquer cliente SQL possui funções de preenchimento automático, mas nem sempre funciona para armazenamentos: raramente possui restrição e chave estrangeira exclusivas para melhorar o desempenho e, sem isso, o programa não consegue descobrir como as entidades estão relacionadas e o que isso pode fazer por você. sugerir.
Tendo passado por negação, raiva, barganha, depressão e aceitação aproximada, eu decidi - por que não tentar implementar o preenchimento automático com blackjack sozinho e como deveria? Eu uso o cliente dbeaver escrito em java, ele tem uma versão da comunidade de código aberto. Um plano simples amadureceu:
- Encontre classes de preenchimento automático no código fonte
- Reoriente-os para trabalhar com metadados externos e extrair informações sobre junções a partir daí
- ??????
- LUCRO
Descobri rapidamente o primeiro item - encontrei uma solicitação para ajustar o preenchimento automático no bugtracker e encontrei a classe SQLCompletionAnalyzer na confirmação relacionada. Eu olhei para o código - o que eu preciso. Resta reescrevê-lo para que tudo funcione. Esperei uma noite livre e comecei a pensar na implementação. Regras de vinculação de tabela (metadados) decidiram liderar em json. Eu não tinha experiência prática com esse formato e a tarefa atual era vista como uma oportunidade para corrigir essa omissão.
Para trabalhar com o json, decidi usar a biblioteca
json-simple do Google. Aqui as surpresas começaram. Como se viu, o dbeaver, como um aplicativo tru, é escrito na plataforma eclipse usando a estrutura OSGi. Para desenvolvedores experientes, isso oferece a conveniência do gerenciamento de dependências, mas para mim era mais como dark magic, para o qual claramente não estava pronto: como de costume, registro a importação das classes de que preciso da biblioteca json-simple no cabeçalho da classe editada, especifico em pom. xml, após o qual o projeto se recusa categoricamente a montar adequadamente e falha com erros.
Como resultado, conseguimos corrigir os erros de montagem: registrei a biblioteca não no pom.xml, mas no manifest.mf, conforme exigido pelo OSGI, enquanto o especificava como pacote de importação. Não é a solução mais bonita, mas funciona. Então a próxima surpresa apareceu. Se você está desenvolvendo uma idéia inteligente, não pode simplesmente obter e executar a depuração do seu projeto com base na plataforma eclipse: um desenvolvedor inexperiente não deve sofrer menos que um analista sem o preenchimento automático de solicitações. Os próprios desenvolvedores de castores vieram ao resgate, indicando no wiki todas as danças com um pandeiro que precisa ser feito. O mais irritante é que, mesmo depois de todos esses agachamentos, o projeto não queria iniciar a depuração com a biblioteca json conectada via import-package (apesar do fato de ainda ter sido montado com êxito no produto final).
Naquele momento, eu senti a inconveniência de usar o json para minha tarefa - afinal, os metadados deveriam ser editados manualmente e, para isso, o formato xml é mais adequado. O segundo argumento a favor do xml foi a presença no JDK de todas as classes necessárias, o que tornou possível parar de brigar com uma biblioteca externa. Com grande prazer, transferi todos os metadados de json para xml e continuei editando a lógica do 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,
fiz alterações nas classes SQLUtils e SQLCompletionAnalyzer. A idéia é a seguinte: se o programa falhou em encontrar frases de auto-preenchimento adequadas de acordo com a lógica básica, ele verifica possíveis junções usando um arquivo xml externo. O próprio arquivo contém pares de tabelas indicando os campos pelos quais essas tabelas precisam ser vinculadas. Restrições nas datas de validade técnica das entradas eff_dttm e exp_dttm e o sinalizador de exclusão lógica delete_ind são definidas por padrão.
Quando foram feitas alterações no código, surgiu a pergunta - quem preencherá o arquivo de metadados? Existem muitas entidades no repositório; não é lucrativo registrar todas as conexões você mesmo. No final, decidi pendurar essa tarefa em meus colegas analistas. O arquivo de metadados foi carregado no svn, de onde os checkouts são feitos em um diretório local com o programa. O princípio é este: uma nova entidade apareceu no repositório? Um analista possibilita a junção ao arquivo, confirma as alterações, o restante faz verificações para si e gosta de trabalhar no preenchimento automático: comunidade, acumulação de conhecimento e tudo mais. Realizou um workshop para colegas sobre o uso do programa, escreveu um artigo em confluência - agora a empresa possui mais de uma ferramenta conveniente.
O trabalho nesse recurso me deu a entender que não se deve ter medo de escolher projetos de código aberto - como regra geral, eles têm uma arquitetura clara e até o conhecimento básico da linguagem será suficiente para experimentos. E com um certo grau de perseverança, você pode até se livrar das odiadas operações de rotina, economizando tempo para novas experiências.