SqlManager#getResultList() creates all entity instances and returns a list which contains them. If SQL returns a large result, it causes OutOfMemory.
In these case, you should use SqlManager#iterate() instead of SqlManager#getResultList().
Integer result = sqlManager.iterate(
Book.class,
new IterationCallback<Book, Integer>() {
private int result;
@Override public Integer iterate(Book entity) {
result = result + entity.price;
return result;
}
},
SQL_PREFIX + "SqlManagerImplTest_selectBooks.sql");
SqlManager#iterate() accepts IterationCallback and invoke it per record. The return value of SqlManager#iterate() is a last returned value from IterationCallback.
Iteration search would be available in Mirage 1.0.3.
2 件のコメント:
Indeed, quite a practical improvement :).
Do you have any performance comparisons for the two approaches?
Also there's an interesting project - JaQu:
http://www.h2database.com/html/jaqu.html
that might have some interesting ideas for Mirage (the configuration there in the POJO is however not a good idea, but the rest is quite nice).
George posted there some very interesting "conventions" (good defaults) that I think would be very very good for Mirage too (and any ORM too :) ) :
http://tinyurl.com/good-defaults
> Do you have any performance comparisons for the two approaches?
No, however getResultList() obviously causes OutOfMemory for large results.
> Also there's an interesting project - JaQu:
> http://www.h2database.com/html/jaqu.html
Thanks, I also found some interesting projects in the Similar Projects section.
These products focus to type safe query builder using Java API. Mirage focuses to 2waySQL as SQL template engine.
Thanks for practical information!
コメントを投稿