galishaДобрый день !

То выживет ли Hibernate ?
Нет ли у него утечек памяти ?
Насколько он хуже по скорости работы, если просто выкачать выбору в List и передать ее Bean.


Выживет. Утечек не бывает. Но если хотите в каждую отдельную страницу помещать 40 записей, то читайте только эти 40 - зачем 40* 40 всякий раз читать?...

Вот как я это делаю:


Здесь int start - начальная позиция в списке, int pageSize - размер страницы, List dest - буфер выбранных записей (класса AccountTransaction). Сначала делаем выборку идентификаторов (значений первичного ключа), потом достаем нужные записи. Возвращаемое значение - hasNext - тоже немаловажно. Если оно true, занчит, есть еще записи, и в форме, показывающей список, можно показать кнопочку "Следующие".

vas0вообще я для постраничного просмотра пользуюсь Query



Да, это проще. В коде. В исполнении код будет извлекать записи, пока не достигнет beginIndex. Заметьте, ПОЛНЫЕ ЗАПИСИ. Это не так дешево, как кажется. В моем случае до start и затем от start до start + pageSize - 1 извлекаются только ID (1 поле).

Представьте, что у вас 10000 записей, и вам надо достать с 5000-й по 5049-ю. У вас впустую зачитаются 4999 ПОЛНЫХ записей, затем с пользой дела зачитаются 50. В моем случае зачитаются 4999 "бесполезных" ID, затем 50 "полезных" и 50 записей. Большая разница. То есть проще не значит лучше.

Кроме того, писать
просто, но некачественно. Следует писать
Понятно, почему?...

ZelenНедавно проект смигрейтил

Правильнее сказать "смайгрейтил" (migrate произносится как "майгрэйт"). Можно еще "мигранул" (от русского "мигрировать").

vas0p М.Голованов
Понятно, почему?...нет

Объясняю. Вы просто складываете 4 строки. Код будет работать так.

1. Выделится буфер под сумму 1 и 2 строк.
2. Они по очереди скопируются в него. Это буфер 1-2.
3. Выделится буфер по сумму 1-2 и 3 строк.
4. Они по очереди скопируются в него. Это буфер 1-2-3.
5. Выделится буфер по сумму 1-2-3 и 4 строк.
6. Они по очереди скопируются в него. Это буфер 1-2-3-4 - то есть результат операции.

Итого последовательно выделяются 3 буфера и выполняется копирование 6 строк.

При использовании StringBuffer:

1. Создастся объект.
2. запомнится ссылка на 1-ю строку.
3. запомнится ссылка на 2-ю строку.
4. запомнится ссылка на 3-ю строку.
5. запомнится ссылка на 4-ю строку.
6. Выделится буфер под сумму всех строк.
Строки 1-4 по очереди скопируются в него - это будет результат.

Экономия на выделениях памяти и копированиях строк очевидна. Для 4-х склеиваемых строк она будет не так велика, но если вы склеиваете их десятками (что не так уж редко при конструировании SQL и Hibernate запросов в коде Java), выигрыш будет весьма ощутим.

http://builder.com.com/5100-6373-5031999.html

котыобязательно используйте hibernate annotations - это избавляет от трудоемких ревизий xml-маппингов при любом изменении модели данных.

Да-да, обязательно!... А еще лучше используйте XDoclet - тогда XML mappings будут генериться вообще автоматически...

Zelen М.Голованов[quot vas0]вообще я для постраничного просмотра пользуюсь Query

Вот здесь можно поподробнее?
Почему Вы думаете что он будет извлекать "пустые" (всмысле "ненужные") записи вообще? Если мне не изменяет память, то как минимум в Hibernate3, указанные команды (выше vas0 вроде) -- в SQL превратятся в нечто "limit X, Y", где X - сколько тянуть, а Y - offset. Что ни при каком раскладе не сделает чтобы база вытягивала "ненужные" записи.

В принципе вы правы. Товарищ использует MySQL, а он реализует LIMIT, поэтому уже как минимум Hibernate 2.1.* будет исполнять код, приведенный vas0, корректно и "лишние" записи извлекаться не будут. Все верно.

Мой код не зависит от того, поддерживает ли СУБД LIMIT или нет. В случае же конкретно MySQL, Oracle, MS SQL следует использовать setFirstResult / setMaxResults. Для этих (и практически всех остальных СУБД за редким исключением) соответствующий Hibernate Dialect имеет

klopuaразве первое при компиляции во второе не превращается?

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/StringBuffer.html String buffers are used by the compiler to implement the binary string concatenation operator +.

Все верно. Превращается. Я извиняюсь, но я имел в виду несколько другое - преимущества привычки явно использовать StringBuffer при составлении динамических SQL - запросов.

Да, в рассмотренном выше случае нет необходимости явно использовать StringBuffer - он будет использован неявно, и выигрыша не будет никакого. А вот другой пример:

String queryStr = "from " + className;
if( condition != null ){
queryStr += " " + condition;
}
if( order != null ){
queryStr += " " + order;
}

Нетрудно видеть, что в этом случае код

StringBuffer query = new StringBuffer( "from " ).append( className );
if( condition != null ){
query.append( " " ).append( condition );
}
if( order != null ){
query.append( " " ).append( order );
}
String queryStr = query.toString();

будет в общем эффективнее. А по жизни приходится составлять куда более "кудрявые" запросы.

То есть я хотел сказать, что в принципе лучше привыкать использовать StringBuffer при склеивании строк всегда. Разница в нотации (количестве нажатий кнопок клавиатуры) невелика, зато не надо думать, что вот в этом случае сойдет, а вот в этом надо бы так...