Hibernate ORM и "ленивый" JOIN
От: Blazkowicz Россия  
Дата: 08.05.07 13:10
Оценка:
Всем привет!

К сожалени в послденее время в связи со спецификой работы я все больше теоретик чем практик. Поэтому вроде бы простые задачи порой ставят в тупик. Вот столкнулся с практической ситуацией и решил её кривым костылем. Был бы благодарен если общественность порсвятит меня на счет возможных решений.

Суть проблемы. Есть две сущности в БД. И ассоциация между ними. Через FK.

HBPhoneCallBean и HBSubjectBean. В 99% случаев в проекте эта ассоциация не нужна. Но вот появился случай когда она понадобилась. И вот мои догадки по которым бы хотелось получить комментарии.
1) Если банально прописать маппинг many-to-one, то получается HBSubjectBean будет выбиратся в 99% случаев где он не нужен. Создавая дополнительную нагрузку на базу. Вопрос, если прописать fetch="join", получается выборка будет через джоин. Значит ли что оверхед при этом будет довольно мал. И им можно было бы принебречь?
2) Если many-to-one сделать ленивым, то в 99% оверхеда не будет. Зато проблемы начнутся в моем единственном случае. Так как выборка происходит сразу толстого списка HBPhoneCallBean, то при ленивой загрузке HBSubjectBean будет выбрана каким-нибудь тормозным способом, подозреваю что отделmным запосом на каждый HBPhoneCallBean. Что убъет производительносьт операции наповал.

После этих раздумий я сделал через Ж. Благо весь проект такой и моей маленькой лажи никто не заметит.

public class HBPhoneCallBean extends HBTrackingBean{

    public static class JoinInmate extends HBPhoneCallBean{
        private HBSubjectBean subject;
        public HBSubjectBean getSubject(){
            return subject;
        }
        public void setSubject(HBSubjectBean subject){
            this.subject = subject;
        }
    }



    <class
        name="HBPhoneCallBean$JoinInmate"
        polymorphism="explicit"
        table="subject_telephone_call">
        <id name="pk" column="pk" type="java.lang.Long">
            <generator class="native"/>
        </id>

        <many-to-one
            name="subject"
            column="fk_subject"
            class="HBSubjectBean"
            insert="false"
            update="false"
            />


Аттрибут polymorphism="explicit" оказался критическим дабы предотвратить дублирование данных разных классов при выборке списка.

В глаза бросаются сразу 2 недостатка. Дублирование маппинга и введение новой сущности только для того чтобы решить порблему уровня persistence.

Буду премногоблагодарен за комментарии и рекомендации как решить проблему одними только маппингами.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.