T'agrada repetir les operacions rutinàries una i altra vegada? Així que no. Però cada vegada al client SQL quan treballava amb l'emmagatzematge de Rostelecom, havia de registrar manualment totes les unions entre les taules. I això malgrat que en el 90% dels casos els camps i les condicions per unir taules coincideixen de petició a petició! Sembla que qualsevol client SQL té funcions d'autocompleció, però per als emmagatzematges no sempre funciona: poques vegades inclouen restricció única i clau estrangera per tal de millorar el rendiment, i sense això el programa no sabrà com es relacionen les entitats amb cadascuna. altre i el que pot fer per oferir-te.
Després d'haver passat per la negació, la ira, la negociació, la depressió i l'acceptació aproximada, vaig decidir: per què no intentar implementar l'emplenament automàtic amb el blackjack jo mateix i fer-ho de la manera correcta? Jo faig servir el client dbeaver, escrit en java, té una versió de la comunitat de codi obert. Un pla senzill ha madurat:
- Cerqueu classes al codi font responsables de la compleció automàtica
- Redirigeix-los per treballar amb metadades externes i extreure informació sobre les unions d'allà
- ??????
- PROFIT
Vaig descobrir el primer punt força ràpidament: vaig trobar una sol·licitud al rastrejador d'errors per ajustar l'emplenament automàtic i en el va descobrir la classe SQLCompletionAnalyzer. Vaig mirar el codi i és el que necessito. Només queda reescriure-ho perquè tot funcioni. Vaig esperar una nit lliure i vaig començar a pensar en la implementació. Vaig decidir escriure regles d'enllaç de taula (metadades) en json. No tenia experiència pràctica treballant amb aquest format i la tasca actual es va veure com una oportunitat per corregir aquesta omissió.
Per treballar amb json vaig decidir utilitzar la biblioteca de Google. Aquí va començar les sorpreses. Com a resultat, dbeaver, com a aplicació real, es va escriure a la plataforma Eclipse mitjançant el marc OSGi. Per als desenvolupadors experimentats, això fa que sigui convenient gestionar les dependències, però per a mi era més com una màgia fosca, per a la qual evidentment no estava preparat: com de costum, importo les classes que necessito de la biblioteca json-simple a la capçalera de la classe editada, especifiqueu-la al pom xml, després del qual el projecte es nega categòricament a muntar-se amb normalitat i es bloqueja amb errors.
Al final, vaig aconseguir corregir els errors de compilació: vaig registrar la biblioteca no a pom.xml, sinó al manifest manifest.mf, tal com ho requereix OSGI, mentre l'especificava com a paquet d'importació. No és la solució més bonica, però funciona. Aleshores va aparèixer la següent sorpresa. Si esteu desenvolupant a Intellij Idea, no podeu començar a depurar el vostre projecte basat en la plataforma eclipse: un desenvolupador sense experiència hauria de patir ni més ni menys que un analista sense completar la consulta. Els mateixos desenvolupadors de castors van venir al rescat, indicant a la wiki tots els balls amb tamborí que cal fer. El més molest és que, fins i tot després de totes aquestes ocupacions, el projecte no volia llançar-se en depuració amb la biblioteca json connectada mitjançant un paquet d'importació (malgrat que encara es va muntar amb èxit al producte acabat).
En aquell moment, ja m'havia adonat dels inconvenients d'utilitzar json per a la meva tasca; després de tot, se suposava que les metadades s'havien d'editar manualment i el format xml és més adequat per a això. El segon argument a favor de xml va ser la presència de totes les classes necessàries al JDK, cosa que va permetre deixar de lluitar amb una biblioteca externa. Amb molt de gust, vaig transferir totes les metadades de json a xml i vaig començar a editar la lògica d'autocompletar.
Exemple de metadades
<?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>Com a resultat jo a les classes SQLUtils i SQLCompletionAnalyzer. La idea és la següent: si el programa no ha pogut trobar suggeriments d'autocompletar adequats mitjançant la lògica bàsica, comprova la presència de possibles unions mitjançant un fitxer xml extern. El propi fitxer emmagatzema parells de taules que indiquen els camps amb els quals s'han d'enllaçar aquestes taules. Les restriccions sobre les dates de validesa tècnica dels registres eff_dttm i exp_dttm i la marca d'eliminació lògica deleted_ind s'estableixen per defecte.
Quan es van fer canvis al codi, va sorgir la pregunta: qui omplirà el fitxer amb metadades? Hi ha moltes entitats al repositori, és car registrar totes les connexions tu mateix. Com a resultat, vaig decidir assignar aquesta tasca als meus companys analistes. Vaig publicar el fitxer de metadades a svn, des d'on es fa una compra al directori local amb el programa. El principi és el següent: ha aparegut una nova entitat al repositori? Un analista introdueix possibles associacions a l'arxiu, fa canvis, la resta es revisa per si mateix i gaudeix de l'autocompleció de treball: comunitat, acumulació de coneixement i tot això. Vaig realitzar un taller per als meus col·legues sobre l'ús del programa, vaig escriure un article a Confluence; ara l'empresa té una eina més convenient.
Treballar amb aquesta funció em va donar la comprensió que no cal tenir por de jugar amb els projectes de codi obert: per regla general, tenen una arquitectura clara i fins i tot el coneixement bàsic del llenguatge serà suficient per a experiments. I amb una certa persistència, fins i tot podreu desfer-vos de les operacions rutinàries odiades, estalviant-vos temps per a nous experiments.
Font: www.habr.com