есть у меня к примеру два класса Member и Order на которых сделан маппинг двух таблиц БД, так вот, а мне вот к примеру нужно вывести информацию в JSP,
т.е. список пользователей, а также сколько у кого какой баланс, т.е. получается если бы я делал запросом, то объеденял бы две таблицы и получал бы одну таблицу с данными. А как сделать для JSP, чтобы я мог как говорится из одного листа читать, т.е. мне нужно создавать еще какой то третий класс??? не хочется же перебирать всех мемберов и делать запросы по Order.

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

__>есть у меня к примеру два класса Member и Order на которых сделан маппинг двух таблиц БД, так вот, а мне вот к примеру нужно вывести информацию в JSP,
__>т.е. список пользователей, а также сколько у кого какой баланс, т.е. получается если бы я делал запросом, то объеденял бы две таблицы и получал бы одну таблицу с данными. А как сделать для JSP, чтобы я мог как говорится из одного листа читать, т.е. мне нужно создавать еще какой то третий класс??? не хочется же перебирать всех мемберов и делать запросы по Order.
Сделай вьюху, которая будет по order считать баланс и замапь её на новую сущность.

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

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

__>>есть у меня к примеру два класса Member и Order на которых сделан маппинг двух таблиц БД, так вот, а мне вот к примеру нужно вывести информацию в JSP,
__>>т.е. список пользователей, а также сколько у кого какой баланс, т.е. получается если бы я делал запросом, то объеденял бы две таблицы и получал бы одну таблицу с данными. А как сделать для JSP, чтобы я мог как говорится из одного листа читать, т.е. мне нужно создавать еще какой то третий класс??? не хочется же перебирать всех мемберов и делать запросы по Order.
B>Сделай вьюху, которая будет по order считать баланс и замапь её на новую сущность.

Можно и без вьюхи — на запрос замапить.

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

GIV>Можно и без вьюхи — на запрос замапить.
Вьюха по идее даёт запас для оптимизации в будущем. Например балансы считать на каждый запрос будет накладно, тогда можно сделать в базе что вьюха будет пересчитыватся при апдейтах, а сами запросы будут работать шустро.
Если запрос оставить в Java сервере, то для такой оптимизации все равно придется ломать сам сервер.

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

GIV>>Можно и без вьюхи — на запрос замапить.
B>Вьюха по идее даёт запас для оптимизации в будущем. Например балансы считать на каждый запрос будет накладно, тогда можно сделать в базе что вьюха будет пересчитыватся при апдейтах, а сами запросы будут работать шустро.
B>Если запрос оставить в Java сервере, то для такой оптимизации все равно придется ломать сам сервер.

Баланс обычно хранится посчитанным. А так не вижу причин мешающих в дальнейшем при необходимости из запроса сделать вьюшку как впрочем и наоборот.

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

GIV>Баланс обычно хранится посчитанным.
Чем гарантируется целостность?

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

Еще один вопрос из этой же оперы. Не хочу просто создавать новую тему.

Вот есть сущности Member и Order.

Мне нужно вывести список ордеров, но, нужно напротив каждого ордера видеть имя Member'a, а в Order
от мембера есть только memberId. Не хотелось бы в таком случае ради одного поля делать вьюху, что на счет такой задачи, что скажете??

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

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

__>Еще один вопрос из этой же оперы. Не хочу просто создавать новую тему.

__>Вот есть сущности Member и Order.

__>Мне нужно вывести список ордеров, но, нужно напротив каждого ордера видеть имя Member'a, а в Order
__>от мембера есть только memberId. Не хотелось бы в таком случае ради одного поля делать вьюху, что на счет такой задачи, что скажете??

В БД в таблице order есть только memberId, но в объекте Order нужно иметь не memberId, а member типа Member (про мапинг читайте здесь). Я так понимаю, что свойство member не всегда нужно при работе с Order, тогда по умолчанию в мапинге делайте его lazy, а конкретно в этом случае в запросе его явно подтягивайте

from Order o inner join fetch o.member

Этот запрос вытащит все заказы и проинициализирует в них поля member.

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

KRA>В БД в таблице order есть только memberId, но в объекте Order нужно иметь не memberId, а member типа Member (про мапинг читайте здесь). Я так понимаю, что свойство member не всегда нужно при работе с Order, тогда по умолчанию в мапинге делайте его lazy, а конкретно в этом случае в запросе его явно подтягивайте

KRA>

KRA>from Order o inner join fetch o.member 
KRA>

KRA>Этот запрос вытащит все заказы и проинициализирует в них поля member.

в теории все понятно, а можно пример? а то еще в хибернейта опыта нет особого, только простой маппинг делал. особенно интересно посмотреть на примере как делать lazy и куда прописывать запрос.

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

__>в теории все понятно, а можно пример? а то еще в хибернейта опыта нет особого, только простой маппинг делал. особенно интересно посмотреть на примере как делать lazy и куда прописывать запрос.

Вот пример использования Lazy

//...

@Entity
@Table(name = "USR")
@SequenceGenerator(name = "USER_SEQ", sequenceName = "USER_SEQ", allocationSize = 1)
public class User  {

    private UserGroup group;

    //...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "GROUP_ID")
    public UserGroup getGroup() {
        return group;
    }

    public void setGroup(UserGroup group) {
        this.group = group;
    }
}

Пример выполнения запроса (тут выбирается одна запись)

        session.createQuery("from TrafficSource as ts where ts.foreignChannelId = :foreignChannelId and ts.server.id = :serverId")
                .setParameter("foreignChannelId", foreignChannelId)
                .setParameter("serverId", serverId)
                .uniqueResult();

В Вашем случае можно обойтись и critria api, как по мне это предпочтительней, т.к. присутствует контроль типов как минимум. Для Вашего случая запрос будет выглядеть так
getSession

session.createCriteria(Order.class).setFetchMode("member", FetchMode.JOIN).list();