Hogyan szüntessük meg az ismétlődést?

Szereted újra és újra megismételni a rutinos műveleteket? Én nem. De minden alkalommal, amikor a Rosztelkom tárolójával dolgoztam az SQL-kliensben, minden egyes kapcsolatra kézzel kellett megadnom a táblák közötti összeköttetéseket. Pedig az esetek 90%-ában a mezők és a táblák összekapcsolásának feltételei az egyes lekérdezésekből adódóan megegyeztek! Úgy tűnik, bármelyik SQL-kliens rendelkezik automatikus kitöltés funkcióval, de a tárolók esetében ez nem mindig működik: ritkán állítanak be unique constraintet és foreign keyt a teljesítmény növelése érdekében, és enélkül a program nem tudja, hogyan kapcsolódnak egymáshoz az entitások, és mit javasolhat neked.

Miután átestem a tagadáson, a haragon, a vásáron, a depresszión, és közeledve az elfogadáshoz, úgy döntöttem – miért ne próbálnám meg én is az automatikus kitöltést blackjackkel és a megfelelő módon? Én a dbeaver klienssel dolgozom, amely java nyelven készült, van egy közösségi verziója is nyílt forrással. Összeállt egy egyszerű terv:

1. Megkeresni a forráskódban az automatikus kitöltésért felelős osztályokat
2. Átirányítani őket, hogy külső metadadatokkal dolgozzanak, és onnan húzzák be az információt a csatlakozásokról
3. ??????
4. NYERESÉG

Az első ponttal viszonylag gyorsan végeztem — találtam a hibakövetőben egy kérést az automatikus kitöltés javítására, és a kapcsolódó commitben felfedeztem az SQLCompletionAnalyzer osztályt. Átnéztem a kódot – éppen az, amire szükségem volt. Csak át kellett írnom úgy, hogy minden működjön. Vártam egy szabad estét, és elkezdtem kidolgozni a megvalósítást. A táblák közötti kapcsolatok szabályait (metadadatokat) json formátumban akartam tárolni. Nem volt gyakorlatom ezzel a formátummal, és a jelenlegi feladat lehetőséget adott arra, hogy ezt a hiányosságot pótoljam.

A json kezelésére a json-simple bibliotékát szerettem volna használni a Googletól. Itt kezdődtek a meglepetések. Mint kiderült, a dbeaver, mint igazi alkalmazás, az Eclipse platformon készült OSGi keretrendszer használatával. A tapasztalt fejlesztők számára ez a dolog kényelmesen kezeli a függőségeket, számomra viszont inkább sötét varázslatnak tűnt, amire egyértelműen nem voltam felkészülve: általában egyszerűen megírom a szükséges json-simple osztályok importját a módosítandó osztály fejlécében, megadom a pom.xml-ben, majd a projekt kategorikusan nem hajlandó normálisan összegyűlni, és hibákkal összeomlik.

A build error was fixed: the library was declared not in pom.xml, but in the manifest manifest.mf, as required by OSGI, indicating it as an import-package. It's not the prettiest solution, but it works. Then a new surprise appeared. If you're developing in IntelliJ IDEA, you can't just run the debug of your project based on the Eclipse platform: an inexperienced developer must suffer as much as an analyst without query autocompletion. The Beaver developers helped by detailing the necessary steps in the wiki. The most frustrating part is that even after all this, the project refused to start in debug mode with the JSON library connected via import-package (even though it successfully built into the final product).

By that time, I had experienced the inconvenience of using JSON for my task — after all, the metadata was supposed to be edited manually, and the XML format fits that purpose better. A second argument for XML was the availability of all necessary classes in the JDK, which allowed me to stop struggling with the external library. I happily transferred all the metadata from JSON to XML and began editing the autocompletion logic.

Example of metadata

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

As a result, I made changes to the SQLUtils and SQLCompletionAnalyzer classes. The idea is this: if the program fails to find suitable autocompletion suggestions through its basic logic, it checks for possible joins based on the external XML file. The file contains pairs of tables with fields that need to be linked. By default, the technical date constraints for the records, eff_dttm and exp_dttm, and the logical deletion flag, deleted_ind, are set automatically.

Amikor a kódba módosításokat végeztek, felmerült a kérdés — ki fogja kitölteni a metaadatfájlt? Az adattárban sok entitás van, nem lenne gazdaságos mindet manuálisan összekapcsolni. Végül úgy döntöttem, hogy ezt a feladatot a kolléga-analitikusaimra bízom. A metaadatfájlt feltöltöttem az svn-re, ahonnan a program lokális mappájába történik a checkout. Az elv a következő: megjelent egy új entitás az adattárban? Egy analitikus bejegyzi a lehetséges kapcsolódásokat a fájlba, elkötelezi a változtatásokat, a többiek pedig checkout-ot végeznek maguknak, és örömmel élvezik az automatikus kitöltést: közösség, tudás felhalmozás és hasonlók. Workshopot tartottam a kollégák számára a program használatáról, írtam egy cikket a Confluence-be — most már van a cégnek egy új, kényelmes eszköze.

A funkción való munka során megértettem, hogy nem érdemes félni az open source projektek bogarászásától — általában érthető architektúrával rendelkeznek, és még a nyelv alapvető ismeretei is elegendőek lesznek kísérletezéshez. Ha pedig megvan a kellő kitartás, akár a gyűlölt rutinfeladatoktól is megszabadulhatunk, időt spórolva az új kísérletekre.

Forrás: habr.com