როგორ შევწყვიტოთ იგივე

მოგწონთ რუტინული ოპერაციების განმეორებით გამეორება? ასე რომ, მე არა. მაგრამ ყოველ ჯერზე, როდესაც SQL კლიენტში როსტელეკომის საცავთან მუშაობისას, მე უნდა დავრეგისტრირდე ყველა შეერთება ცხრილებს შორის ხელით. და ეს იმისდა მიუხედავად, რომ 90% შემთხვევაში ცხრილების შეერთების ველები და პირობები ემთხვეოდა მოთხოვნიდან მოთხოვნამდე! როგორც ჩანს, ნებისმიერ SQL კლიენტს აქვს ავტომატური დასრულების ფუნქციები, მაგრამ საცავებისთვის ის ყოველთვის არ მუშაობს: ისინი იშვიათად შეიცავენ უნიკალურ შეზღუდვას და უცხო კლავიშს შესრულების გაუმჯობესების მიზნით, და ამის გარეშე პროგრამა არ იცის, თუ როგორ არის დაკავშირებული ერთეულები თითოეულთან. სხვა და რისი გაკეთება შეუძლია მას თქვენთვის.

უარყოფის, გაბრაზების, ვაჭრობის, დეპრესიის და მიმღებლობის მოახლოების შემდეგ გადავწყვიტე - რატომ არ ვცადო ბლექჯეკის ავტომატური შევსების განხორციელება და ამის გაკეთება სწორად? მე ვიყენებ dbeaver კლიენტს, დაწერილი java-ში, მას აქვს ღია კოდის საზოგადოების ვერსია. მარტივი გეგმა მომწიფდა:

1. იპოვეთ კლასები საწყის კოდში, რომლებიც პასუხისმგებელნი არიან ავტომატურ დასრულებაზე
2. გადამისამართეთ ისინი გარე მეტამონაცემებთან მუშაობაზე და იქიდან ამოიღეთ ინფორმაცია შეერთების შესახებ
3. ??
4. მოგების

პირველი პუნქტი საკმაოდ სწრაფად გავარკვიე - შეცდომების ტრეკერში ვიპოვე მოთხოვნა ავტომატური შევსების კორექტირების შესახებ და მასთან დაკავშირებულ ჩაიდინოს აღმოაჩინა SQLCompletionAnalyzer კლასი. კოდს გადავხედე და ის არის რაც მჭირდება. რჩება მხოლოდ მისი გადაწერა ისე, რომ ყველაფერი იმუშაოს. ველოდებოდი თავისუფალ საღამოს და დავიწყე ფიქრი განხორციელების შესახებ. გადავწყვიტე დამეწერა ცხრილის ბმულის წესები (მეტამონაცემები) json-ში. ამ ფორმატთან მუშაობის პრაქტიკული გამოცდილება არ მქონდა და დღევანდელი დავალება მიიჩნიეს ამ გამოტოვების გამოსწორების შესაძლებლობად.

json-თან მუშაობისთვის გადავწყვიტე ბიბლიოთეკის გამოყენება json-მარტივი Google-ისგან. აქედან დაიწყო სიურპრიზები. როგორც გაირკვა, dbeaver, როგორც ნამდვილი აპლიკაცია, დაიწერა Eclipse პლატფორმაზე OSGi ფრეიმერის გამოყენებით. გამოცდილი დეველოპერებისთვის ეს ხელს უწყობს დამოკიდებულებების მართვას, მაგრამ ჩემთვის ეს უფრო ბნელ მაგიას ჰგავდა, რისთვისაც აშკარად არ ვიყავი მზად: ჩვეულებისამებრ, მე იმპორტირებს კლასები, რომლებიც მჭირდება json-simple ბიბლიოთეკიდან სათაურში. რედაქტირებულ კლასს, მიუთითეთ ის პომ.xml-ში, რის შემდეგაც პროექტი კატეგორიულ უარს ამბობს ნორმალურად აწყობაზე და იშლება შეცდომებით.

საბოლოოდ მოვახერხე build-ის შეცდომების გამოსწორება: ბიბლიოთეკა დავრეგისტრირდი არა pom.xml-ში, არამედ manifest.mf manifest-ში, როგორც ამას OSGI მოითხოვდა, იმავდროულად დავაფიქსირე როგორც import-package. არ არის ყველაზე ლამაზი გამოსავალი, მაგრამ მუშაობს. შემდეგ მორიგი სიურპრიზი გამოჩნდა. თუ თქვენ ვითარდებით Intellij Idea-ში, არ შეგიძლიათ უბრალოდ წახვიდეთ და დაიწყოთ თქვენი პროექტის გამართვა eclipse პლატფორმაზე დაფუძნებული: გამოუცდელი დეველოპერი უნდა დაზარალდეს ანალიტიკოსზე არანაკლებ შეკითხვის დასრულების გარეშე. თავად თახვის დეველოპერები მივიდნენ სამაშველოში, ვიკიში მიუთითეს ყველა ცეკვა ტამბურით, რომელიც უნდა გაკეთდეს. ყველაზე შემაშფოთებელი ის არის, რომ მთელი ამ ჩაჯდომის შემდეგაც კი, პროექტს არ სურდა გამართულად გაშვება იმპორტ-პაკეტით დაკავშირებულ json ბიბლიოთეკასთან (მიუხედავად იმისა, რომ ის მაინც წარმატებით იყო აწყობილი მზა პროდუქტში).

იმ დროისთვის მე უკვე გავაცნობიერე ჩემი ამოცანისთვის json-ის გამოყენების უხერხულობა - ბოლოს და ბოლოს, მეტამონაცემების ხელით რედაქტირება უნდა მომხდარიყო და xml ფორმატი უფრო შესაფერისია ამისათვის. მეორე არგუმენტი xml-ის სასარგებლოდ იყო JDK-ში ყველა საჭირო კლასის არსებობა, რამაც შესაძლებელი გახადა შეჩერებულიყო ბრძოლა გარე ბიბლიოთეკასთან. დიდი სიამოვნებით გადავიტანე ყველა მეტამონაცემები json-დან xml-ზე და დავიწყე ავტომატური შევსების ლოგიკის რედაქტირება.

მეტამონაცემების მაგალითი

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

შედეგად მე ცვლილებები შეიტანა SQLUtils და SQLCompletionAnalyzer კლასებში. იდეა ასეთია: თუ პროგრამამ ვერ იპოვა შესაბამისი ავტომატური შევსების წინადადებები ძირითადი ლოგიკის გამოყენებით, მაშინ ის ამოწმებს შესაძლო შეერთების არსებობას გარე xml ფაილის გამოყენებით. თავად ფაილი ინახავს ცხრილების წყვილებს, რომლებიც მიუთითებს იმ ველებზე, რომლებითაც ეს ცხრილები უნდა იყოს დაკავშირებული. შეზღუდვები eff_dttm და exp_dttm ჩანაწერების ტექნიკური მოქმედების თარიღებზე და ლოგიკური წაშლის დროშა deleted_ind დაყენებულია ნაგულისხმევად.

როდესაც კოდში ცვლილებები განხორციელდა, გაჩნდა კითხვა - ვინ შეავსებს ფაილს მეტამონაცემებით? საცავში უამრავი ობიექტია, ძვირი ღირს ყველა კავშირის დარეგისტრირება. შედეგად, გადავწყვიტე ეს დავალება დამეკისრა ჩემს თანამემამულე ანალიტიკოსებს. მე გამოვაქვეყნე მეტამონაცემების ფაილი svn-ში, საიდანაც ხდება გადმორიცხვა პროგრამით ადგილობრივ დირექტორიაში. პრინციპი ასეთია: გამოჩნდა თუ არა საცავში ახალი ობიექტი? ერთი ანალიტიკოსი შეაქვს ფაილში შესაძლო შეერთებებს, ცვლის ცვლილებებს, დანარჩენები ამოწმებენ საკუთარ თავს და სარგებლობენ სამუშაო ავტომატური დასრულებით: საზოგადოება, ცოდნის დაგროვება და ეს ყველაფერი. ჩაატარა სემინარი კოლეგებისთვის პროგრამის გამოყენების შესახებ, დაწერა სტატია Confluence-ში - ახლა კომპანიას აქვს კიდევ ერთი მოსახერხებელი ინსტრუმენტი.

ამ მახასიათებლებზე მუშაობამ მომცა იმის გაგება, რომ არ არის საჭირო, შეგეშინდეთ ღია კოდის პროექტებთან შეხების - როგორც წესი, მათ აქვთ მკაფიო არქიტექტურა და ენის საბაზისო ცოდნაც კი საკმარისი იქნება ექსპერიმენტებისთვის. და გარკვეული დაჟინებით, თქვენ კი შეძლებთ თავი დააღწიოთ საძულველ რუტინულ ოპერაციებს, დაზოგოთ დრო ახალი ექსპერიმენტებისთვის.

წყარო: www.habr.com