Здравствуйте, C0s, Вы писали:

C0s>лучше join не делать, хз, как поведёт себя БД, может справится, а может и нет
Тоесть я верно опасался что джоин таки способен нагнуть базу?

B>>После этих раздумий я сделал через Ж. Благо весь проект такой и моей маленькой лажи никто не заметит.
C0s>я бы так не делал =)
Да. Меня совесть грызет. Вот и любопытствую.

B>>Буду премногоблагодарен за комментарии и рекомендации как решить проблему одними только маппингами.

C0s>почему только маппингами?
C0s>я бы как раз посоветовал тюнить код выборки, т.е. для общего случая оставить lazy, а в конкретном уж разобраться так, чтобы отскакивало
Не очень понял как тюнить чтобы отскакивало? Смысл то в том что с lazy все равно как минимум 2 запроса будет. А хотелось бы одним.

B>>2) Если many-to-one сделать ленивым, то в 99% оверхеда не будет. Зато проблемы начнутся в моем единственном случае. Так как выборка происходит сразу толстого списка HBPhoneCallBean, то при ленивой загрузке HBSubjectBean будет выбрана каким-нибудь тормозным способом, подозреваю что отделmным запосом на каждый HBPhoneCallBean. Что убъет производительносьт операции наповал.

C0s>как ты выбираешь "толстый список"?
C0s>например, если через Criteria, то укажи ему явно FetchMode для нужной связки
Да. criteria.list()
То есть ты хочешь сказать если сделать Criteria.setFetchMode(JOIN) то не смотря на lazy в маппинге ассоциация приедет по этому же запросу с минимальными обращениями к БД?