ორი ტრანზაქცია არსებობს. პირველი ტრანზაქცია ასრულებს ბრძანებას. შემდეგ, მეორე ტრანზაქცია ასრულებს ბრძანებას. შემდეგ, პირველი ტრანზაქცია განაგრძობს. რომელი სერია გამოიწვევს ურთიერთბლოკირებას? ```sql -- პირველი ტრანზაქცია update accounts set balance = balance + 100 where id = ?; -- მეორე ტრანზაქცია update accounts set balance = balance - 50 where id = ?; update accounts set balance = balance + 200 where id = ?; ```
ბოტების ტრეფიკის წილი ანტიფროდ გუნდი შეიმუშავა მექანიზმი ბოტების ტრეფიკის გამოვლენისათვის მაღაზიის საიტზე: როდესაც ბოტი შედის საიტზე, მის URL-ის პარამეტრებში ემატება ქვესრია "bot" (დიდა და პატარა ასოების განსხვავება არ არის). თუ user_id ერთდროულად მინიმუმ ერთხელ დეკემბერში არის დადგენილი როგორც ბოტი, ის ყოველთვის უნდა განიხილებოდეს როგორც ბოტი. შეისწავლეთ მომხმარებლების ვიზიტების მონაცემთა ნაკრები და გამოითვალეთ ბოტების წილი საერთო მომხმარებელთა რაოდენობის მიმართ დეკემბერში 2024 (დაწვრილებით ერთ ციფრამდე). შესავალი ფორმატი ტაბლია visits: - event_date (date) — ვიზიტის თარიღი - user_id (int) — უნიკალური მომხმარებლის იდენტიფიკატორი - url (string) — ბმული, რომლის მეშვეობითაც განხორციელდა ვიზიტი მონაცემები არ შეიცავს გამოტოვებულ ან არასწორ მნიშვნელობებს. გამოსვლის ფორმატი საკითხი უნდა დაბრუნდეს ცხრილი შემდეგ ველებით: - share (float) — ბოტების წილი საერთო მომხმარებელთა რაოდენობის მიმართ დეკემბერში, ერთ ციფრამდე დაწვრილებით.
როგორ აღვადგინოთ შორეული ფილიალიდან სამუშაო, თუ ცდილობთ `git checkout hotfix/missing-footer` და მიიღებთ შეცდომის შეტყობინებას, რომ ფილიალი არ მოიძებნა?
პროექტის უწყვეტი მუშაობის უზრუნველსაყოფად, მინიმალური რისკით ყველა ფილიალში უსაფრთხოების ხარვეზის აღმოფხვრის რა სტრატეგია იქნება ეფექტური? - პრობლემური კომიტის და ყველა იმ კომიტის სერიის შექმნა, რომლებიც ნაწილობრივ გამოსწორდა, შემდეგ სრული გამოსწორებით ახალი კომიტის შექმნა - hotfix-ფილიალის შექმნა პრობლემურ კომიტამდე წერტილიდან, გამოსწორებების განხორციელება და ამ ფილიალის გაერთიანება ყველა დაზარალებულ ფილიალთან - ერთიანი გამოსწორების კომიტის შექმნა git revert abc123-ის გამოყენებით მთავარი ფილიალში და შემდეგ ამ კომიტის cherry-pick-ი ყველა გამოშვების ფილიალზე - git bisect-ის გამოყენება პრობლემური კოდის ზუსტი განსაზღვრებისთვის, პაჩის შექმნა და მისი გამოყენება ყველა ფილიალში git am-ის საშუალებით - git rebase -i-ის გამოყენება პრობლემური კომიტის რედაქტირებისთვის თითოეულ ფილიალში, შემდეგ force-push-ის (force-push) განხორციელება
მომხმარებელთა აქტივობის ანალიზი რეკლამების კამპანიებში კომპანია აკონტროლებს მოვლენებს, რომლებიც დაკავშირებულია რეკლამების კამპანიებთან. შესასვლელი ცხრილები: • campaigns — რეკლამების კამპანიების სია, მათ იდენტიფიკატორებთან და სახელწოდებებთან; • events — მომხმარებლების მოვლენები კამპანიების მიხედვით, მათ შორის მოვლენების ტიპი (მაგალითად, 'click' (კლიკი რეკლამაზე)) და დრო. საჭიროა თითოეული რეკლამების კამპანიისთვის ანგარიშის შექმნა შემდეგი მაჩვენებლებით: • საერთო მოვლენების რაოდენობა. • უნიკალური მომხმარებლების რაოდენობა, რომლებმაც განახორციელეს მოვლენები. • კამპანიის პირველი და ბოლო მოვლენების დრო. • კამპანიის რეიტინგი საერთო მოვლენების რაოდენობის მიხედვით კლებადობით. რეიტინგი — რიცხვი, რომელიც მიენიჭება თითოეულ ხაზს შედეგების ნაკრებში მონაცემების მითითებულ წესზე დაყრდნობით. თუ ორი ან მეტი ხაზი აქვს ერთნაირი მნიშვნელობა, მათ მიენიჭებათ ერთნაირი რეიტინგი, მაგრამ შემდეგი რეიტინგი გამოტოვებულია. შესაბამისი კამპანიები, რომელთაც ჰქონდათ მოვლენები, ანგარიშში შედიან: მოვლენების გარეშე კამპანიები არ განიხილება. საბოლოო ანგარიში უნდა იყოს პირველ რიგში რეიტინგით ზრდადობით, შემდეგ კი campaign_name-ის მიხედვით ალფავიტურად. შესასვლელი ფორმატი • campaign_name (string) — რეკლამების კამპანიის სახელი • start_date (timestamp) — კამპანიის დაწყების დრო • end_date (timestamp) — კამპანიის დასრულების დრო მონაცემთა ცხრილი: • event_id (int) — უნიკალური იდენტიფიკატორი • user_id (int) — უნიკალური მომხმარებლის იდენტიფიკატორი, რომელმაც განახორციელა მოვლენა • campaign_id (int) — კამპანიის უნიკალური იდენტიფიკატორი • event_type (string) — მოვლენის ტიპი, მაგალითად 'click' (კლიკი) ან 'conversion' (გადამოწმება — წარმატებული მოქმედება, მაგალითად, შეძენა) • event_time (timestamp) — მოვლენის შესრულების დრო მონაცემები არ შეიცავს გამოტოვებებს ან არასწორ მნიშვნელობებს. გამოსავლის ფორმატი საკითხი უნდა დააბრუნოს ცხრილი შემდეგ ველებით: • campaign_name (string) — რეკლამების სახელი • total_events (int) — საერთო მოვლენების რაოდენობა • unique_users (int) — უნიკალური მომხმარებლების რაოდენობა, რომლებმაც განახორციელეს მოვლენები • first_event_time (timestamp) — პირველი მოვლენის დრო • last_event_time (timestamp) — ბოლო მოვლენის დრო • campaign_rank (int) — კამპანიის რეიტინგი საერთო მოვლენების რაოდენობის მიხედვით კლებადობით მონაცემები უნდა იყოს რეიტინგით ზრდადობით, შემდეგ კი campaign_name-ის მიხედვით ალფავიტურად.
თუ გსურთ შეცვალოთ ფილიალი, რომელსაც მიუთითებს სუბმოდული, რა უნდა გააკეთოთ? - სუბმოდულები არ უჭერენ მხარს ფილიალების შეცვლას - წაშალეთ სუბმოდული და დაამატეთ იგი ახალი ფილიალით - შეცვალეთ ფილიალი სუბმოდულში და შეასრულეთ კომიტი მთავარ რეპოზიტორიაში - შეასრულეთ git checkout სასურველ ფილიალზე სუბმოდულში და დარეგისტრირეთ ცვლილებები მთავარ რეპოზიტორიაში - შეასრულეთ git submodule update --branch და მიუთითეთ ახალი ფილიალი
რა მოხდა და როგორ აღვადგინოთ სამუშაო?
რატომ განიხილავთ ამჟამად სამუშაო შეთავაზებებს?
notifications jadvali status maydoni mavjud bo'lib, uning qiymatlari: 'sent', 'delivered', 'read'. Qaysi so'rov to'g'ri? select * from notifications where status like '%sent%' order by created_at desc limit 5 select * from notifications where status = 'read' order by created_at desc limit 5 select * from notifications order by status desc limit 5 select * from notifications where status not in ('sent', 'delivered') order by created_at asc limit 5 select * from notifications where status in ('sent', 'delivered') order by created_at desc limit 5
რა ოპერაცია განახორციელა ბრძანებამ? - განახორციელა git revert იმ კომიტზე, სადაც იყო config.yaml - განახორციელა git filter-branch --index-filter "git rm --cached config.yaml" -- --all - განახორციელა git rebase -i, წაშლის კომიტებს, რომლებიც შეიცავდნენ ფაილში ცვლილებებს - განახორციელა git commit --amend და git push --force - გამოიყენო git cherry-pick ახალი ფილიალის შესაქმნელად, სადაც config.yaml არ არის
PostgreSQL-შ, სარჩევის ვერსიის სათაურში შედის xmax პარამეტრი. რა როლი აქვს მას ტრანზაქციების მართვაში? - უნიკალური სარჩევის იდენტიფიკატორის შექმნისთვის - სარჩევის ხილვადობის შემოწმებისთვის სხვა ტრანზაქციების მიერ - ტრანზაქციის ნომრის მითითებისთვის, რომელმაც სარჩევი წაშალა ან განაახლა - სარჩევის ერთდროულ ცვლილებებზე რამდენიმე ტრანზაქციისგან დაცვაში - მაქსიმალური მნიშვნელობის მითითებისთვის, რომელიც შეიძლება იყოს დაწერილი რიცხვით სვეტში
სურათზე მოცემული ცხრილების სტრუქტურა შექმნილია. საჭიროა სურათზე მოცემული სვეტით სარეკლამო მოთხოვნის შესრულება. [...]-ის ადგილას რა სახის join უნდა გამოიყენოს, რათა შედეგში type = 'table_aw'-ისთვის 'naming' სვეტი შეივსოს, ხოლო type = 'table2'-ისთვის — 'serial_number' სვეტი? create table multirelation( type varchar not null, entity_id integer not null ); create table table_aw( id integer primary key, naming varchar not null ); create table table2( id integer primary key, serial_number varchar not null ); -- ცხრილების სტრუქტურა select m.type,m.entity_id, ta.naming, t2.serial_number from multirelation m [...] join table_aw ta on m.entity_id = ta.id and m.type='table_aw' [...] join table2 t2 on m.entity_id = t2.id and m.type='table2'; -- სარეკლამო მოთხოვნა გაწყვეტილიყავით ცარიელი inner cross right left
გთხოვთ, გვითხარით, რატომ გსურთ ეს ვაკანსია.
ფიტნეს კლუბების ვიზიტების ანალიზი თქვენ მუშაობთ ფიტნეს კლუბების ქსელში ანალიტიკოსად. გაქვთ ინფორმაცია მომხმარებლების ვიზიტებზე და მათ მიერ შეძენილ აბონემენტებზე. საჭიროა აბონემენტების ეფექტიანობის ანალიზი. გაანგარიშეთ თითოეული აბონემენტის ტიპისთვის: • ამ ტიპის აბონემენტს გამოყენებული მომხმარებლების საერთო რაოდენობა. მოიცილეთ მხოლოდ უნიკალური user_id-ები; • ამ აბონემენტთან დაკავშირებული ვიზიტების საერთო რაოდენობა. მოიცილეთ ყველა ვიზიტი ამ აბონემენტით დაკავშირებული მომხმარებლების; • ამ აბონემენტის მომხმარებლების წილი საერთო მომხმარებელთა რაოდენობაში პროცენტებში (ერთი ათწილადამდე მორგებული). მომხმარებლების წილის გამოთვლისთვის გამოიყენეთ ამ აბონემენტის მომხმარებლების რაოდენობის და საერთო უნიკალური მომხმარებლების რაოდენობის შეფარდება. ყოველ მომხმარებელს შეუძლია ჰქონდეს მხოლოდ ერთი აბონემენტი. შედეგი sort-ით დაალაგეთ აბონემენტის ტიპის მიხედვით ალფაბეტურ წესრიგში. შესავალი ფორმატი ცხრილი memberships: • membership_id (int) — უნიკალური აბონემენტის ID • user_id (int) — მომხმარებლის უნიკალური ID • membership_type (text) — აბონემენტის ტიპი ცხრილი visits:
რომელი ბრძანება უნდა გამოიყენოს პროექტის ძირითადი საქაღალდიდან, რათა განაახლოს submodule docs/ მოლაპარაკების ბოლო ვერსიამდე და ამ ცვლილების მომზადება კომიტისთვის? git fetch docs/ && git merge docs/FETCH_HEAD git pull --recurse-submodules git submodule update --remote docs/ cd docs/ && git pull && cd .. && git commit -am "განახლება" git submodule update --init docs/
რამდენიმე Scala პროექტზე მუშაობდით ადრე? გაითვალისწინეთ კონკრეტული დავალებები და მიღწევები ამ ტექნოლოგიაში.
რა მოხდა და როგორ დავუბრუნოთ სამუშაო?
რა შეიძლება ითქვას შემდეგი შეკითხვის სისწორეზე? select * from sessions where ended_at is null and status != 'pending';
შენ გაქვს ორი დაკავშირებული სია: first_table და second_table. გსურს შეასრულო ბრძანება TRUNCATE TABLE second_table CASCADE;, რათა წაშალო ყველა სარჩევი second_table-დან და ყველა დამოკიდებული მონაცემი. რა შედეგები შეიძლება ჰქონდეს ამ ბრძანების შესრულებას? create table first_table ( id integer primary key ); create table second_table ( id serial primary key, first_table_fk integer references first_table(id) ); - second_table_id_seq სექვენსია აღდგება საწყის მნიშვნელობაზე. - ყველა ჩანაწერი first_table-დან, რომელიც დაკავშირებულია second_table-თან გარეგანი გასაღვით, წაიშლება. - არსებული ინდექსები second_table-ისთვის წაიშლება და ავტომატურად აღდგება. - შემდგომი შეტანებისას second_table-ში, id-ისთვის დეფოლტ მნიშვნელობა შეიძლება დაიწყოს არასწორ მნიშვნელობიდან. - შეცდომა მოხდება, რადგან CASCADE ბრძანება აკრძალულია გარეგანი გასაღებით სიაებისთვის.
ლოგისტიკის კომპანიისთვის ანგარიში თქვენ ხართ ლოგისტიკური კომპანიის ანალიტიკოსი, რომელიც აკრეფს ოპერაციებს საწყობებში. უნდა მოამზადოთ ანგარიში თითოეული საწყობი ეფექტურობის შესახებ. თითოეული საწყობი გამოითვალეთ: • საერთო ოპერაციების რაოდენობა (count_operations); • საწყობში დამუშავებული საერთო საქონლის რაოდენობა (sum_quantity); • ოპერაციის საშუალო დრო (avg_processing_time), მხოლოდ მითითებული დროის ოპერაციებისთვის (არ NULL), მრგვლივ მთელ რიცხვად; • მაქსიმალური და მინიმალური საქონლის რაოდენობა, რომელიც ერთ ოპერაციაში დამუშავდა (max_quantity, min_quantity); • თითოეული ტიპის ოპერაციების რაოდენობა («მიწოდება», «გაგზავნა», «გადატანა») ცალკე სვეტებში: supply_operations, shipment_operations, transfer_operations. ფილტრეთ საწყობები, რომელთა საერთო ოპერაციების რაოდენობა აღემატება 2-ს და საშუალო დრო არ აღემატება 60 წუთს. შედეგი sort-ით დაალაგეთ საწყობი ID-ის მიხედვით ზრდადობით. შესავალი ფორმატი ოპერაციების სია: • operation_id (int) — ოპერაციის უნიკალური ID • warehouse_id (int) — საწყობის ID • operation_type (text) — ოპერაციის ტიპი: «მიწოდება», «გაგზავნა», «გადატანა»
