Hibernate bug iliti Šta kad alat zataji?

Nedavno smo na projektu koji radimo naišli na Hibernate bug. Neobičnost se ogleda u tome što bug ne zahteva neke posebne i specifične specijalne uslove - a to je nešto što se ne očekuje od zrelog i vremešnog open-source projekta kao što je Hibernate. Reč je o sledećem: bilo je potrebno uvezati dva entiteta preko bidirekcione one-to-many veze, pri čemu se za uvezivanje ne koristi primarni ključ izvornog entiteta (source), već neko drugo polje (tkzv. nemušti ključ) čija je vrednost, opet, generisana spolja, od strane baze. Na primer, treba uvezati Customer i Address entitete na opisani način, gde jedan Customer može da ima nula, jednu ili više Address-a. Customer sadrži uobičajen primarni ključ (id), ali i nemušti ključ (linkId), generisan od strane baze, koji služi za referenciranje od spolja. Entiteti Address su uvezani na ovaj nemušti ključ. Za Hibernate je ovo još uvek nesavladiv problem. Posle dugotrajnog čačkanja i mukotrpnih debagovanja, uočeno je da se generisana vrednost ključa ne pročita kada treba, te sve prestaje da radi.

Naravno, bug je odmah prijavljen i dat je kompletan primer kako se dolazi do njega. Posle par dana, bag je prihvaćen, ali mu je nivo prioriteta smanjen na 'Minor'. Za Hibernate community to nije tako značajan problem - ko to još uostalom ne koristi primarni ključ za referenciranje, a pri tome ga generiše u bazi! Bag je još uvek otvoren i ne postoje nikakve indikacije da bi mogao da bude rešen u skorije vreme. Jedini je problem što je ovaj bag bio stopirajući za projekat koji je odmakao sa razvojem. Srećom, relacioni model se mogao izmeniti kako bi napravili rešenje koje Hibernate razume i koje će raditi posao, ali koje logički nije sasvim korektno.

Tema ovog kratkog članka nije diskusija u vezi relacionog modela, jer ima dobrih razloga zašto je takav - u krajnjem slučaju, takvi su bili klijentovi zahtevi. Umesto toga, vredi se ponekad zapitati:

• Šta raditi kada korišćeni alat jednostavno - ne radi?
• Koliko dobro poznajemo alate koje koristimo?
• Koliko zaista smemo da se oslonimo na druge alate?

Šta uraditi u ovakvom slučaju?

Imate sors, pa ispravite

Hm, da. Nije lako ući u projekat koji ima >1100 java fajlova. Pogotovo nije lako naći način ispraviti nešto što zahteva veće razumevanja načina na koji radi takva biblioteka. I naravno, kako objasniti klijentu da je potrebno odvojiti neznanu količinu vremena, koje on plaća, na to da se ispravi nešto što i nije u direktnoj poslovnoj vezi sa projektom?

Naći tehničku podršku

Hm, da. Platiti nekome da možda pronađe rešenje za bug. Verovatno efikasnije, ali i skuplje od prethodnog primera.

Mešanje tehnologija

Pustiti da ono što radi kako treba bude pod Hibernate-om, a ono što ne radi bude pod nekom drugom tehnologijom. Najmanje lepo rešenje.

In-House rešenja

Danas se možda ovaj pristup previše stavlja u drugi plan. Ako postoji dobra in-house količina znanja, odvojiti 1-2 nedelje/čovek dana za pravljenje nečega što će zadovoljiti ne-tako-uopšten skup zahteva uopšte ne mora da bude 'loša stvar', pogotovo ako dobijeno rešenje zadovoljava potrebe jednog ili više projekata. Ipak, velike opasnosti leže u ovom pristupu, te je potrebno imati dosta praktičnog znanja i iskustva.

Analiza, analiza

Možda bi najispravnije bilo napraviti dobru analizu projekta. U trenutku kada su zahtevi manje-više formulisani i kada se mogu uočiti najkritičniji delovi (s tehnološkog stanovišta), a opet pre prve iteracije projekta, trebalo bi napraviti male pilot probe koje bi služile kao dokaz da je koncept u redu i da je korišćena tehnologija dobro izabrana. No, opet, imali uvek vremena za to :)?