@OneToMany ანოტაცია

ვაგრძელებთ ისევ Hibernate-ს ანოტაციების განხილვას და ამ პოსტში განვიხილოთ @OneToMany ანოტაცია. Hibernate-ში @OneToMany ანოტაცია განსაზღვრავს ერთი ბევრთან კავშირს. მაგალითად ერთ პიროვნებას აქვს ბევრი ტელეფონის ნომერი. თუმცა ამ ანოტაციასთან ერთად გამოიყენება @JoinColumn ანოტაცია, რომელიც განსაზღვრავს იმას, რომ ეს კონკრეტული entity (რომელშიც ეს ანოტაცია წერია) არის კავშირის მფლობელი (owner). ხოლო ატრიბუტი, mappedBy მიუთითებს იმაზე, რომ entity ამ მხარეში არის კავშირის უკუგება, ანუ სხვა სიტყვებით რომ ვთქვათ, ეს entity არ არის კავშირის „მფლობელი“ (owner). ამ კავშირის დროს გვაქვს კიდევ ერთი fetch ატრიბუტი, რომელიც განსაზღვრავს კავშირის დამყარებას როგორ ჩაიტვირთოს დაკავშირებული ობიექტი. მაგალითად, თუ Person კლასს აქვს PhoneNumber-ების სია თავის ველად, და fetch არის default, ანუ Lazy, მაშინ Person-ების გამოტანისას არ წამოყვება ტელეფონის ნომრები და ეს წამოღება მხოლოდ მაშინ მოხდება, როცა უკვე მივმართავთ ტელეფონის ნომრებს. ვნახოთ რა ხდება ამ დროს SQL-ში. 

Main-ში უბრალოდ ვეძებთ პიროვნებას, რომლის ID არის 1 და ვბეჭდავთ მის ტელეფონის ნომრებს (ამ შემთხვევაში მთავარი ისაა, რომ ამ ველს მივმართავთ)

ახლა ვნახოთ რა Query გაეშვა მონაცემთა ბაზაზე 

როგორც ხედავთ გაეშვა ორი Query: ერთ პიროვნების წამოღება და მეორე პიროვნების მიხედვით ტელეფონის ნომრების წამოღება. ახლა ვნახოთ რა მოხდება თუ fetch-ს გავხდით EAGER-ს.

როგორც სურათიდან ჩანს, ორი Query-ის მაგივრად გაეშვა ერთი და ტელეფონების ნომრები წამოიღო პიროვნების წამოღებასთან ერთად. ანუ ეს Query შეიცავს დაკავშირების ბრძანებასაც LEFT OUTER JOIN

@Embedded ანოტაცია

ვაგრძელებთ წინა პოსტში განხილულ თემატიკას და ამ პოსტში გაგაცნობთ Hibernate-ს @Embeddable და @Embedded ანოტაციებს, რომლებიც საქმეს ერთად აკეთებენ. სანამ უშუალოდ მაგალითზე გადავიდოდე, მოვიყვან შემთხვევას როდის შეიძლება გამოვიყენოთ ეს ანოტაციები. მაგალითად, გვაქვს Person კლასი შესაბამისი ცხრილით მონაცემთა ბაზაში. დავუშვათ, რომ ამ ცხრილში ინახება ადამიანის მისამართი რამდენიმე ველის სახით. მაგალითად: საფოსტო კოდი, ქალაქი, ქვეყანა, ქუჩა. ცხადია, რომ ოთხი სხვადასხვა ველით წარმოდგენა არც ისე დიდი პრობლემაა, მაგრამ რას იტყოდით, ამ ველების ერთ Address ობიექტში "გახვევაზე" ? ანუ მონაცემთა ბაზაში ასე ცალ-ცალკე ველად იქნება, მაგრამ ჯავას კოდში ამ ოთხ ველზე ვიმოქმედებთ როგორც Address კლასზე. შემდეგი სურათები გვიჩვენებს სწორედ ამ მაგალითს.  ჩვენ აღვწერთ Address კლასს შესაბამისი ველებით და ამ კლასს თავზე დავაწერთ @Embeddable ანოტაციას. შემდეგ Address კლასის ტიპის ველი გვექნება Person კლასში და ამ ველს დავაწერთ @Embedded ანოტაციას.

@MappedSuperclass ანოტაცია

საკმაო დრო გავიდა მას შემდეგ რაც ბოლო პოსტი დავწერე პროგრამირების შესახებ და გადავწყვიტე "თავი შეგახსენოთ". ამ პოსტში განვიხილავ Hibernate-ის ორ ანოტაციას, რომლებიც ჩემი აზრით გარკვეული ამოცანების გადაჭრაში მნიშვნელოვნად შეამცირებს დახარჯულ დროსა და ენერგიას და კოდსაც მისცემ უკეთეს სახეს.

მაშ ასე, მოდით დავიწყოთ @MappedSuperclass-ით. თითქმის ყველა აპლიკაციაში, რომელიც იყენებს მონაცემთა ბაზებს, ყველა ცხრილში გვაქვს ისეთი ველები, რომლებიც არის საერთო. მაგალითად, პირადი გამოცდილებიდან რომ გითხრათ, თითქმის ყველა პროექტში, ყველა ცხრილში მქონდა შემდეგი სამი ველი : CREATE_DATE, UPDATE_DATE, USER_ID. ამ შემთხვევაში თავი დავანებოთ იმას, რომ ყველა ცხრილს აქვს Primary Key და სიმარტივისთვის შეგვიძლია ყველა ცხრილში მას ID დავარქვათ და გამოვიყენოთ ასევე ზემოთ ხსენებული ანოტაცია. მოკლედ, თუ თქვენც გქონიათ ასეთი შემთხვევა, ალბათ ძალიან მოგბეზრებიათ თითოეული ცხრილის შესაბამის Entity-ში ამ სამი ველის აღწერა (ჩაკოპირება). ჯავა და კერძოდ Hibernate ამ მოსაბეზრებელი საქმის მოგვარებაში გვეხმარება @MappedSuperclass ანოტაციით. იდეა მდგომარეობს იმაში, რომ აღვწერთ კლასს, რომელშიც აღვწერთ საერთო ველებს და ამ კლასს დავაწერთ ზემოთ ხსენებულ ანოტაციას. შემდეგ ყველა Entity-ის გავხდით ზემოთ ხსენებული კლასის მემკვიდრეს. მოდით ვნახოთ მაგალითზე. საერთო ველების მქონე კლასს მე CommonFields-ს დავარქვი. ვთქვათ მაქვს ორი Entity: Person და Product.

აქვე დავაანონსებ, რომ შემდეგ პოსტსაც Hibernate-ის ანოტაციაზე შემოგთავაზებთ.