| | 1 | = Проблеми со Lazy Exception = |
| | 2 | |
| | 3 | Ако добиете порака за Lazy Exception значи дека некаде не сте работеле правилно и треба нештата да ги направите поинаку. Сфатете го како да ви вика софтверот дека сте Lazy :) |
| | 4 | |
| | 5 | Поточно и попрецизно - се работи за следното. Преку сервисите сте повлекле некој објект Ентитет, сте правеле некои операции и го предавате или како параметар или преку Persist на друга страница или на страницата сама на себе ама после redirect. При таквото пренесување врската до базата може да биде прекината (и нормално е да биде) и ентитетот се „откачува“ од матичната табела и останува сам (осамен во РАМ) и неповрзан со останатиот дел од базата. |
| | 6 | |
| | 7 | Кај така пренесениот неповрзан ентитет не може да се користат неговите вградени „линкови“ кон други ентитети без разлика дали се работи за 1:н или н:1 врска, затоа што при користење на таквите врски е потребно hibernate да има остварно врска до базата и да креира SQL кој тоа ќе го овозможи. |
| | 8 | |
| | 9 | Пример сте пренеле од една на друга страна student и сакате да го видите неговото име. Но името не е дел од student, туку е во person со кој е поврзан дадениот student. |
| | 10 | Во нормална околност можете да направите student.person.firstName и ќе го добиете името. |
| | 11 | Меѓутоа ако објектот е откачен тогаш student.person е невозможно да се извржи и ќе добиете Lazy exception. |
| | 12 | |
| | 13 | Решение за ова е или да го осмислите предавањето аргументи на некој друг начин или пак да го користите предадениот неповрзан објект, како критериум за да го пронајдете неговиот оригинал во базата и потоа да работите со новиот. |
| | 14 | |
| | 15 | Идеално и најчист начин на програмирање е ниту една работа од базата да не се користи во веб страниците, туку само во DAO класите. Запаметете и секое „рипање“ преку надворешен клуч, како во student.person.firstName инволвира операција за природно спојување во базата на податоци меѓу табелите за student и person. |
