Como deixar de facer o mesmo

Gústache repetir operacións rutineiras unha e outra vez? Entón non. Pero cada vez que no cliente SQL cando traballaba co almacenamento de Rostelecom, tiña que rexistrar todas as unións entre as táboas manualmente. E iso a pesar de que no 90% dos casos os campos e condicións para unir táboas coincidían de solicitude a solicitude! Parece que calquera cliente SQL ten funcións de autocompletar, pero para os almacenamentos non sempre funciona: raramente inclúen restricións únicas e chave estranxeira para mellorar o rendemento, e sen iso o programa non saberá como se relacionan as entidades con cada un. outro e o que pode facer por ti ofrecer.

Despois de pasar por negación, enfado, negociación, depresión e achegandome á aceptación, decidín: por que non tentar implementar o autocompletado co blackjack e facelo da maneira correcta? Eu uso o cliente dbeaver, escrito en java, ten unha versión da comunidade de código aberto. Un plan sinxelo madurou:

1. Busca clases no código fonte que son responsables do autocompletado
2. Redirixilos para que traballen con metadatos externos e extraian información sobre as unións desde alí
3. ??
4. LUCRO

Descubrín o primeiro punto con bastante rapidez: atopei unha solicitude no rastreador de erros para axustar o enchemento automático e nos datos relacionados. comprometerse descubriu a clase SQLCompletionAnalyzer. Mirei o código e é o que necesito. Só queda reescribilo para que todo funcione. Agardei unha noite libre e comecei a pensar na implementación. Decidín escribir regras de ligazón de táboa (metadatos) en json. Non tiña experiencia práctica traballando con este formato e a tarefa actual foi vista como unha oportunidade para corrixir esta omisión.

Para traballar con json decidín usar a biblioteca json-simple de Google. Aquí comezaron as sorpresas. Como se viu, dbeaver, como unha verdadeira aplicación, foi escrito na plataforma Eclipse usando o marco OSGi. Para os desenvolvedores experimentados, isto fai que sexa conveniente xestionar dependencias, pero para min foi máis como maxia escura, para a que claramente non estaba preparado: como de costume, importo as clases que necesito da biblioteca json-simple na cabeceira de a clase editada, especifícao no pom.xml, despois de que o proxecto négase categóricamente a montar normalmente e falla con erros.

Ao final, conseguín corrixir os erros de compilación: rexistrei a biblioteca non en pom.xml, senón no manifesto manifest.mf, tal e como esixe OSGI, mentres a especificaba como paquete de importación. Non é a solución máis bonita, pero funciona. Entón apareceu a seguinte sorpresa. Se estás a desenvolver en Intellij Idea, non podes comezar a depurar o teu proxecto baseado na plataforma eclipse: un programador sen experiencia debería sufrir nada menos que un analista sen completar a consulta. Os propios desenvolvedores de castores acudiron ao rescate, indicando na wiki todos os bailes con pandeireta que hai que facer. O máis molesto é que aínda despois de todas estas ocupacións, o proxecto non quería lanzarse en depuración coa biblioteca json conectada mediante un paquete de importación (a pesar de que aínda se ensamblaba con éxito no produto acabado).

Nese momento, xa me decatara do inconveniente de usar json para a miña tarefa; despois de todo, os metadatos debían editarse manualmente e o formato xml é máis axeitado para iso. O segundo argumento a favor de xml foi a presenza de todas as clases necesarias no JDK, o que permitiu deixar de loitar cunha biblioteca externa. Con gran pracer, transferín todos os metadatos de json a xml e comecei a editar a lóxica de autocompletar.

Exemplo de metadatos

<?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 I fixo cambios nas clases SQLUtils e SQLCompletionAnalyzer. A idea é a seguinte: se o programa non puido atopar suxestións de autocompletar adecuadas usando a lóxica básica, comprobará a presenza de posibles unións mediante un ficheiro xml externo. O propio ficheiro almacena pares de táboas que indican os campos polos que estas táboas deben vincularse. As restricións sobre as datas de validez técnica dos rexistros eff_dttm e exp_dttm e a marca de eliminación lóxica deleted_ind están definidas por defecto.

Cando se fixeron cambios no código, xurdiu a pregunta: quen encherá o ficheiro con metadatos? Hai moitas entidades no repositorio, é caro rexistrar todas as conexións por ti mesmo. Como resultado, decidín asignarlle esta tarefa aos meus compañeiros analistas. Publiquei o ficheiro de metadatos en svn, desde onde se realiza un checkout ao directorio local co programa. O principio é este: apareceu unha nova entidade no repositorio? Un analista introduce posibles unións no ficheiro, comete cambios, o resto pásase por si mesmo e goza da autocompletación de traballo: comunidade, acumulación de coñecemento e todo iso. Realizou un obradoiro sobre o uso do programa para compañeiros, escribiu un artigo en Confluence - agora a empresa ten unha ferramenta máis conveniente.

Traballar nesta función deume a comprensión de que non hai que ter medo de xogar con proxectos de código aberto: por regra xeral, teñen unha arquitectura clara e ata o coñecemento básico da linguaxe será suficiente para os experimentos. E con certa persistencia, incluso poderás desfacerte das odiadas operacións rutineiras, aforrando tempo para novos experimentos.

Fonte: www.habr.com