Nola utzi gauza bera egiteari

Ohiko eragiketak behin eta berriro errepikatzea gustatzen al zaizu? Beraz, ez dut. Baina SQL bezeroan Rostelecom biltegiarekin lan egitean, taulen arteko lotura guztiak eskuz erregistratu behar izan ditut. Eta hori kasuen %90ean taulak batzeko eremuak eta baldintzak kontsultaz kontsulta bat zetozen arren! Badirudi edozein SQL bezeroak automatikoki osatzeko funtzioak dituela, baina biltegietarako ez du beti funtzionatzen: gutxitan sartzen dituzte muga bakarra eta kanpoko gako errendimendua hobetzeko, eta hori gabe programak ez du jakingo entitateak bakoitzarekin nola erlazionatzen diren. beste eta zer egin dezakeen eskaintzen dizu.

Nola utzi gauza bera egiteari

Ukazioa, haserrea, negoziazioa, depresioa eta onarpena hurbildu ondoren, erabaki nuen: zergatik ez saiatu blackjack-arekin autobetetzea ezartzen eta modu egokian egiten? dbeaver bezeroa erabiltzen dut, javaz idatzia, kode irekiko komunitatearen bertsioa du. Plan sinple bat heldu da:

  1. Bilatu iturburu-kodean osatze automatikoaz arduratzen diren klaseak
  2. Birbideratu itzazu kanpoko metadatuekin lan egiteko eta hortik elkartzeei buruzko informazioa ateratzeko
  3. ??
  4. PROFIT

Lehen puntua nahiko azkar asmatu nuen - akatsen jarraipenaren eskaera bat aurkitu nuen betetze automatikoa doitzeko eta erlazionatutako konprometitu SQLCompletionAnalyzer klasea aurkitu du. Kodea begiratu nuen eta behar dudana da. Dena funtziona dezan berridaztea besterik ez da geratzen. Arratsalde libre bat itxaron eta ezarpena pentsatzen hasi nintzen. Taularen esteken arauak (metadatuak) json-en idaztea erabaki nuen. Ez nuen formatu honekin lan egiten esperientzia praktikorik eta oraingo zeregina hutsune hori zuzentzeko aukera gisa ikusi zen.

Json-ekin lan egiteko liburutegia erabiltzea erabaki nuen json-sinple Google-tik. Hor hasi ziren sorpresak. Gertatu zenez, dbeaver, benetako aplikazio gisa, Eclipse plataforman idatzi zen OSGi markoa erabiliz. Garatzaile esperientziadunentzat, gauza honek erosoa egiten du mendekotasunak kudeatzea, baina niretzat magia iluna bezalakoa zen, argi eta garbi ez nengoen horretarako prest: ohi bezala, behar ditudan klaseak inportatzen ditut json-simple liburutegitik goiburuan. editatutako klasea, zehaztu pom.xml-n, eta, ondoren, proiektuak normaltasunez muntatzeari uko egiten dio eta akatsekin huts egiten du.

Azkenean, eraikitze-erroreak konpontzea lortu nuen: liburutegia ez pom.xml-en erregistratu nuen, manifest.mf manifestuan baizik, OSGIk eskatzen duen moduan, inportazio-pakete gisa zehazten nuen bitartean. Ez da irtenbiderik ederrena, baina funtzionatzen du. Orduan hurrengo sorpresa agertu zen. Intellij Idea-n garatzen ari bazara, ezin zara eclipse plataforman oinarritutako zure proiektua arazketan hasi: esperientziarik gabeko garatzaile batek analista batek baino gutxiago jasan beharko luke kontsultak amaitu gabe. Kastoreen garatzaileak beraiek etorri ziren erreskatatzera, wikian egin beharreko dantza guztiak pandero batekin adieraziz. Gogaikarriena da squat guzti horien ondoren ere, proiektua ez zuela abiarazi nahi inportazio-paketearen bidez json liburutegia abiarazi nahi izan (amaitutako produktuan arrakastaz muntatu zen arren).

Ordurako, jada konturatu nintzen nire zereginerako json erabiltzearen eragozpenez; azken finean, metadatuak eskuz editatu behar ziren, eta xml formatua hobeto egokitzen da horretarako. Xml-ren aldeko bigarren argudioa JDKn beharrezko klase guztiak egotea izan zen, eta horri esker, kanpoko liburutegi batekin borrokari uztea posible zen. Plazer handiz, metadatu guztiak json-tik xml-ra transferitu eta autocomplete logika editatzen hasi nintzen.

Metadatuen adibidea

<?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>

Ondorioz I aldaketak egin SQLUtils eta SQLCompletionAnalyzer klaseetan sartu. Ideia hau da: programak ezin izan badu aurkitu oinarrizko logika erabiliz auto-osatzeko iradokizun egokiak, orduan egiaztatzen du balizko elkartzeen presentzia kanpoko xml fitxategi bat erabiliz. Fitxategiak berak taula pareak gordetzen ditu, taula horiek lotu behar diren eremuak adieraziz. Eff_dttm eta exp_dttm erregistroen baliozkotasun-daten murrizketak eta ezabatze logikoaren bandera deleted_ind ezartzen dira lehenespenez.

Kodean aldaketak egin zirenean, galdera sortu zen: nork beteko du fitxategia metadatuekin? Biltegian entitate asko daude, garestia da konexio guztiak zeuk erregistratzea. Ondorioz, zeregin hori nire ikaskide analistei esleitzea erabaki nuen. Metadatuen fitxategia svn-en argitaratu nuen, bertatik programarekin tokiko direktoriora ordaintzea egiten da. Printzipioa hau da: entitate berri bat agertu al da biltegian? Analista batek fitxategian sartze posibleak sartzen ditu, aldaketak konprometitzen ditu, gainontzekoek beren kabuz egiaztatu eta lan-osaketa automatikoaz gozatu: komunitatea, ezagutzaren metaketa eta guzti. Lankideentzako programa erabiltzeko tailerra egin du, artikulu bat idatzi du Confluence-n; orain konpainiak tresna erosoago bat du.

Ezaugarri honetan lan egiteak ulertu nuen ez dagoela kode irekiko proiektuekin beldurrik izan beharrik; normalean, arkitektura argia dute, eta hizkuntzaren oinarrizko ezagutza ere nahikoa izango da esperimentuetarako. Eta nolabaiteko iraunkortasunarekin, errutinazko eragiketa gorrotoak kentzeko gai izango zara, esperimentu berrietarako denbora aurreztuz.

Iturria: www.habr.com

Gehitu iruzkin berria